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ABSTRACT 

This thesis presents a computer simulated model of 
ammunition resupply in a CJ.S. combat battalion. The model 
is based on current ammunition resupply doctrine and has 
been designed as a stand-alone simulation. Additionally, 
this model has been structured to parallel the Simulation of 
Tactical Alternative Responses (STAR) model so that future 
enhancements might include its full integration into rhe 
STAR model. When such an integration is accomplished, the 
important dimension of combat service support will become an 
influencing factor in the decision making process at all 
levels of the combat model. 
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I. INTRODUCTION 



A. GENERAL 

Combat is a complex, multi-dimensional process, the 
nature of which defies simple description. In its broadest 
sense, this process is divided into land, sea, and air 
categories. The Army, for its part, focusing its attention 
on the air/land battle, subdivides the process further into 
Combat, Combat Support, and Combat Service Support 
functions. While it is generally recognized that a total 
picture of combat cannot be gained by looking at any single 
subdivision of the process, this segmentation overlays a 
conceptual framework that brings with it a degree of clarity 
necessary for analysis purposes. 

Computer simulations modelling the air/land battle have 
naturally evolved along these segmented paths. They have, 
however, become so functionalized that they exist today as 
parallel and completely separate worlds seeking to model the 
same phenomenon . The degree to which this segmentation has 
developed was a natural consequence both of hardware 
limitations imposed by older generation computers, and by 
the very complexity of the combat process itself. 
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Modellers, in attempting to present a "total ' 1 picture of 
combat, have erected bridges between these paths with 
varying degrees of success. These bridges generally take 
the form of a Lanchester equation. In practice, a modeller 
concentrates on one path seeking resolution while portraying 
necessary parallel processes in this simplified mathematical 
form. This technique permits the modeller to capture at 
least some measure of the interaction of these paths on 
battle outcome, without necessitating the use of an 
unrealistic amount of computer time. 

The direct consequence of this situation is that while 
usually answering questions directed at some particular 
segment, and amply answering the questions of who, what, and 
when at the interface points between paths, such models do 
not achieve the sharpened focus needed to answer the where, 
how, and why of rhe total process. Perhaps this last set of 
questions is avoided because the answer to them requires 
modelling command logic and synergistic interplay difficult 
to capture and quire conceivably beyond the scope of any one 
model’s charter. At any rate, the loss of this detail 
prevents one from really answering basic questions as to the 
effectiveness and workability of the combined "total" 
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process. In essence, the fundamental question, ’’Can it be 
done?”, is never adequately answered. 

3. LOGISTICS MODELS 

Current logistics models then, although running the 
gamut from high level, high resolution simulations to low 
level, low resolution simulations, must be characterized, in 
accordance with the above arguments, as single dimensional 
models. For, operating independently of any combat model, 
logistics models must generate the demands they respond to 
in some '’artificial” way either externally or internally. 
Externally, data generated from a combat model is converted 
to some record of expenditures and fronr-ended into the 
model as a sequence of events. Internally, the combat 
process is expressed by some form of Lanchester equation 
which dynamically generates specific requirements within the 
context of the model itself. Output from these models is 
then designed to provide a record of activities completed 
over time as a measurement of an organization’s ability to 
respond to a varied requirements load. Logistics 
effectiveness is then examined in aggregated terms, such as 
tons delivered per day, or miles travelled per day. Details 
of inrerplay between the combat and logistical processes are 
generally not available. 
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/fith the development of the Simulation of Tactical 
Alternative Responses (STAR) model at the Naval Postgraduate 
School (NPS) , logisticians have been given a unique 
opportunity to investigate this dynamic interaction between 
combat and logistical processes at the most critical 
juncture, the battlefield. Since its initial coding in 1978, 
the model has been continually expanded to include an ever 
widening horizon of combat functions. Several preliminary 
attempts have been made to integrate logistics into the 
model, but as yet, little logistics is played. 

C. THESIS OBJECTIVES 

In light of the above considerations, a goal of 
developing a rudimentary high resolution logistics module 
was established, with the ultimate aim of the project being 
its eventual integration into the STAR model. After some 
consideration, the project's goal was redefined further and 
effort was centered on the development of an ammunition 
(Class V) model within a combat battalion. Ammunition was 
chosen both because of its critical impact on the 
battlefield and because the logic developed for this class 
of supply could easily be expanded to other classes. Such 
an attempt would represent at least a first step toward 
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capturing the subtle interaction between the combat and 
logistical processes. The project’s plannd approach was to 
have included: 

• A review of previous work done at NP5 in the area of 
resupply. 

• A review of of existing ammunition resupply models 
currently in use within the Army community. 

• Familiarization with the workings of the STAR model with 
the objective of identifying the logical interface 
points for a logistics module. 

• The design of an ammunition resupply model written in 
SIMSCRIPT II. 5 that simulates the resupply process 
within a combat battalion. 

• Integration of this logistics model into STAR at the 
appropriate points so that STAR generated data such as 
ammunition expended, vehicles killed, et cetera, would 
provide a driver for the logistics module. 

• Incorporation of the information provided by the 
logistics module into the company and battalion 
commander decision logic of the STAR model. 

Preliminary forays into the organization, use, and 

operational vicissitudes of the STAR model, however. 
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immediately identified and underscored the primary 
disjuncture between combat and service support models to be 
pace of battle. The plain fact is that the critical time 
window for analysis of operational effectiveness is 
different for the two types of models. High resolution 
combat models generally focus on the inner workings of a 
battle that may last less than four hours. Logistics 
models, in contrast, operate over time spans ranging from 
three to thirty days. In the current STAR model, battles 
generally terminate after three hours, well before the 
logistical network is even alerted for action. Planned 
expansion of the STAR model beyond the brigade battle now 
fought, however, makes the eventual inclusion of logistical 
factors both possible and necessary. 

With these considerations in mind, the initial 
objectives of interfacing directly with the STAR model was 
modified and the planned logistics module was expanded to a 
full stand-alone, high resolution model. Supplementary 
objectives were established in order to achieve the 
completeness of a stand-alone model while keeping the 
ultimate objective of eventual interface with STAR in sight. 
These additional objectives were: 
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• Development of a detailed model that responds to 
requests for ammunition resupply, maintains a simplified 
stockage system, and models the movement of rounds down 
to the individual weapon. 

• Maintenance of an appropriate level of resolution within 
the model. Eventual integration into the STAR model 
dictates that the resupply process must begin with and 
be based on knowledge of expenditures of a variety of 
ammunitions fired by any number of individual systems. 

• Maintenance of a high degree of flexibility within the 
model. The model designed must be flexible enough to 
adapt to the wide variety of tables of organization and 
equipment that might be played in STAR. 

D. THESIS ORGANIZATION 

Chapter II provides an overview of the background 
research which went into the formation of this model. It 
includes a brief outline of current Army ammunition resupply 
doctrine, an overview of two of the most current Army 
models, and an examination of several past logistics theses 
done at the Naval Postgraduate School. 

Chapter III presents the Logistics Model which is the 
primary focus of this thesis. It provides an overview of 
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model functions and explains the major model assumptions. 
Topics discussed include: the battle scenario, requests for 
resupply, the distribution of resupply assets, and the 
redistribution of on-hand assets. 

Chapter IV discusses lessons learned in the construction 
of the model and outlines future areas of consideration for 
model enhancement. 

Appendix A provides an expanded explanation of the 
material mentioned in Chapter III. This section, however, 
presents the material in a form suitable for the reader who 
is familiar with both combat modelling techniques and 
SIMSCRIPT II. 5. 

Appendix B is a detailed explanation of the model code 
itself. It provides the reader with definitions of all 
entities, sets, attributes, and variables used in the model, 
along with a listing and line by line explanation of the 
computer code written. 
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II . STATE OF THE A5T 

A. INTRODUCTION 

This chapter presents an overview of the background 
research that influenced the formation of the ammunition 
resupply model. This information is provided both as a 
ready reference for the works investigated and as a means of 
explaining the underlying rationale of many of the concepts 
later adopted for use in the model. This chapter includes: 
a brief explanation of the current and future Army doctrine 
regarding ammunition resupply; a discussion of two of the 
Army's most up to date ammunition resupply models, HE1APS 
II, and ARM; and an in depth look at past logistics thesis 
efforts pertinent to this model. 

B. AMMUNITION SUPPORT IN TODAY'S ARMY 

Without sufficient ammunition resources a combat unit's 
effectiveness is degraded and the tactical alternatives 
available to its leaders severely restricted. For this 
reason, a procedure, which first seeks an internal solution 
through the redistribution of assets, and then an external 
solution through resupply, is standard regardless of unit 
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type. For example, at platoon or company level the 
redistribution of on-hand ammunition assets is standard 
operating procedure at the conclusion of any move, 
regardless if the move is offensive or defensive. 

When ammunition becomes a dwindling resource on a weapon 
the platoon leader is notified, regardless if the weapon is 
an M-16 or the main gun of an Ml tank. The platoon leader 
then takes appropriate action either by redistributing his 
own platoon resources or requesting resupply from the 
company commander, or both. In a similar fashion, platoon 
shortages are examined at the company level and if necessary 
a resupply request is submitted to battalion. At battalion, 
a support platcon receives requests for resupply from the 
company then issues ammunition from the battalion’s assets. 
This support platoon in turn replenishes its stocks from 
either the brigade ammunition transfer point (ATP) or the 
division ammunition supply point (ASP) . The ATP and ASP in 
turn are supported by a corps storage area (CSA) . A graphic 
representation of a divisional ammunition support structure 
is given in Figure 1. 

The logic that dictates the resupply activity which 
should take place and where it should take place is the 
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CS A - Corps Support Area 

AS? - Ammunition Supply Point 

ATP - Ammunition Transfer Point 



Figure 1: Ammunition Support Structure 



objective of this model. Determination of the correct 
course of logistic action at each level of control from the 
individual weapon up is a function of how much is known 
about the situation at any time. This knowledge is 
admittedly imperfect due to time delays, human error, and 
the stress of battle. To capture the essence of this 
imperfect information flow, a central concept. Level of Need 
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(LON) , was developed to mark thresholds for different 
activities. This concept is explained in detail in Chapter 
III. 

C. EXISTING ARMY MODELS 

The purpose of this section is to present the reader an 
overview of the two most recently developed Army ammunition 
resupply models. The two models are the Human Engineering 
Laboratory Ammunition Foint Simulation (HELAPS II) and the 
Ammunition Resupply Model (ARM) . Although other ammunition 
resupply models exist, the two mentioned above depict 
resupply at a level and degree of resolution that directly 
relates to this thesis. The purpose, characteristics, 
assumptions, input, output, strengths, and weaknesses of 
each model are discussed to provide an overview of the 
ammunition resupply modelling capabilities that are 
available today. The information presented in this chapter 
has been extracted from the referenced literature regarding 
the respective model. 

1 . HE LAPS II 

The initial model for discussion is the HELAPS II 
model. This model was developed by Armament Systems Inc., 
Anaheim, Calif., under contract to the US Army Missle and 
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Munitions Center and School, Directorate of Combat 
Developments, Redstone Arsenal, Alabama. HELAPS II is a 
stochastic, event sequenced simulation that is run on a CD C 
6000 series machine with GASP IV simulation language. The 
model simulates the internal operation of an ammunition 
resupply activity (CS A/ASP/ATP) to include the 
transportation system connecting the resupply point with its 
source of supply and its customers. The model constrains 
the flow of munitions through realistic delays representing 
the limited capability of material handling equipment (MHE) , 
resupply vehicles (RSV's) and personnel operating in an 
environment susceptible to delays due to distance, time, 
weather conditions, integrated battle, and limited 
resources. [Ref. 1] 
a. Purpose 

The HELAPS model is meant to be used as an 
analysis tool for evaluating ammunition resupply activity 
dynamics, operational concepts development, TOE 
design/validation and mission area analysis. HELAPS II does 
this by simulating the movement of resupply vehicles (RSV's) 
from the customer or source element through the 
inprocessing, loading/off-loading operations, out processing 
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activities, and then back to their home elements. These 
activities all occur based on a workload generated in a 
realistic combat scenario. 

b. Characteristics 

The model uses a dynamic, computer, 
force-on-force wargame (ie. JIFFY) to determine the interval 
between resupply convoys by generating expenditures. These 
resupply convoys of up to 15 vehicles are constrained by 
availability of vehicles, distance traveled, enemy attack 
and environmental conditions. When the convoy arrives at 
the resupply point the RSV's are subject to delays caused by 
queues, processing, MHE/personnel availability, stock 
shortages, enemy attack and environmental conditions. 
Reliability, availability and maintainability (RAM) of 
equipment, along with internal resupply activity policies 
are also considered where applicable. Once all elements in a 
convoy are out-processed the convoy returns to its point of 
departure. 

Throughout the running of HELAPS II information 
is collected concerning personnel activities and equipment 
performance. This information is analyzed to determine the 
following: 

(1) MHE/personnel utilization and performance. 



27 



(2) In process ing/out processing delays. 

(3) Capacities for receipt and issue of munitions. 

(4) Optimal stockage objectives. 

(5) Effects of enemy actions on performance to include: 

(a) Physical layout. 

(b) Security requirements. 

(6) Distribution of resupply turn-around times. 

(7) Optimal mix of MHE and RSV's. 

(8) Impact of RAM on mission performance. 

(9) Effectiveness of operating procedures. 

(10) Adequacy of current or proposed TOE's. 

c. Assumptions 

All models make assumptions that play an 
important role in the results generated and analysis 
performed. The assumptions made in the HELAPS II model are 

(1) Resupply requirements for individual weapons are 
consolidated at the firing unit's battalion. 

(2) All resupply activities take place on a 24 hour basis 

(3) Inclement weather, night operations, and enemy 
suppression degrade performance of the resupply 
acti vity. 
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d. Input 

Input data needed to run this simulation 
consists of numerous user entries. Some examples of this 
input data are: 

(1) Distances between firing units and resupply 
activities . 

(2) Distribution of ammunition consumption by firing unit 
for the simulation period. 

(3) Number of personnel available by duty position at the 
resupply activity. 

(4) Amount of stock by type available at the resupply 
activity. 

(5) Assignment of MHE to specific tasks at each resupply 
acti vity. 

(6) Distances between inter-activity elements. 

(7) A scenario of enemy activity. 

(8) All start, stop, and pause times. 

(9) Operating procedures for each resupply activity. 

(10) Environmental conditions by activity. 

(11) Host nation role if applicable. 

(12) Stockage levels for each ammunition type. 
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e. Output 

This input, data will generate output data of the 
following nature: 

(1) Amount of ammunition received and issued at a resupply 
point by type. 

(2) Start and stop stockage levels by ammunition type. 

(3) Discrete and average turn-around times by RSV/convoy. 

(4) Discrete and average processing times both in and out 
of the resupply point by RSV/convoy. 

(5) Discrete and average nonavailability times by 
equipment type. 

f. Strengths 

The major strengths of HELAPS II are its ability 
to accomplish the following: 

(1) Provide a tool to analyze the internal operations of a 
munitions resupply activity at any level. 

(2) Provide inferences as to the total issue capability of 
a designated TOE. 

(3) Collect data on the number of RSV's and convoys 
required to support a unit in a given scenario. 

(4) Provide refined estimates (ie. mean and statisrical 
distribution) of the time required for an RSV or 
convoy to resupply a supported unit. 
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(5) Identify the major choke points of a resupply activity 
and simulate the processing of each vehicle through 
these choke points in sequence. These choke points 
and the sequence in which they occur are as follows: 

(a) aSV/convoy leaves resupply activity. 

(b) RSV/convoy is processed by Ammunition Supply 
Officer. 

(c) RSV/convoy arrives at resupply activity and is 
in-processed . 

(d) The RSV/convcy moves to its respective loading 
point . 

(e) Loading/off-loading takes place. 

(f) RSV/convoy leaves and proceeds to an assembly 
area . 

(g) RSV/convoy out-processed through activity office. 

(h) RSV/convoy returns to initiating activity. 

(6) Give a good evaluation of the effect of enemy activity 
on mission performance by considering the damage and 
destruction of support equipment. 

(7) Provide a good tool for Combat Service Support Mission 
Area Analysis and TOE development. 
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(8) Provide another check on performance of the army's MHE 
design standards for handling munitions. 

(9) Look at scenarios under different environmental 
condition s. 

(10) Provide a tool for choosing the optimal location of 
resupply activities at ail levels. 

(11) Identify security shortcomings for different 
scenarios. 

g. Weaknesses 

The major weaknesses of the model are: 

(1) Munition consumption and threat data bases must be 
developed manually from a force-on-force scenario. 

(2) The model requires extensive computer core memory 
allocation . 

(3) The model is expensive to run. 

2. MU 

The second model to be analyzed is the Ammunition 
Resupply Model (ARM). ARM is an interactive, event 
oriented, time sequenced, computer model developed to 
simulate the various functions associated with ammunition 
resupply from the Corps Storage Area (CSA) down to the 
individual weapon. It was developed by the Combat 



32 



Operations Analysis Directorate (COA) , CASSA, Fort 
Leavenworth, Kansas in March of 1980. ARM is written in 
FORTRAN IV and consists of approximately 3400 lines of code 
that require 144K octal main storage, including the data 
base. Less than 12 CPU seconds are used in processing the 
resupply actions that result from four hours cf combat by a 
division size force. [Ref. 2] 

a. Purpose 

ARM's primary role is to assess the capability 
of a given TOE structure to respond to the logistical 
demands placed on it by various ammunition expenditures. 

For model purposes, these expenditures are created by a 
force-on-force model such as the JIFFY vargame. ARM was 
used in this manner to study the ammunition resupply 
capability of alternative division organizations of the 
Division 86 force structure. The model was developed in a 
general form thereby allowing it to be used with most combat 
models . 

b. Characteristics 

ARM controls the flow of ammunition through a 
network based on the capacity of a given number of RSV's and 
supply points. It also controls the flow through the supply 



33 



network based on MHE availability. The model actually 
forces the network to replace rounds at individual weapons 
at the unit level, and sends trucks back to designated 
resupply points to fill up and return. The functions of 
each truck are broken up into a series of discrete events 
portrayed as subroutines. The model takes each truck 
through a series of these subroutines (with operational 
availability and interdiction considered) in which acrions 
are completed and times accumulated. Helicopter resupply, 
interactive command decisions, and tactical realism can be 
incorporated into the model, 
c. Assumptions 

A list of the key assumptions made in ARM are: 

(1) Only high volume/high demand ammunition is addressed. 

(2) Artillery units reload once each hour during a battle. 

(3) Aviation units reload upon the return of an aircraft. 

(4) Ammunition trucks are dedicated to a specific type of 
ammunition. 

(5) When a weapon system is lost, all ammunition is lost. 

(6) When a loaded truck is interdicted, the load is lost. 

(7) Helicopter emergency resupply will support only 155mm 
artillery batteries and the resupply originates at the 
ASP. 
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(3) Trucks are sent for refill only when empty. 

(9) The division portion of the corps heavy lift 
helicopters will not exceed 10 CH-47's. 

(10) The division portion of corps transportation assets 
for ammunition resupply will be one medium truck 
company. This company will haul ammunition directly 
from the CSA to the ATP's and ASP's. 

/ 

d. Input 

The input parameters needed for the operation of 
the model are: 

(1) Number and allocation of ammunition dedicated 
HSV’ s/con voys in the transportation net. 

(2) Record of on-hand ammunition from the scenario 
wargame. 

(3) Number of weapons and basic load of each type system. 

(4) Ammunition hauling capacity of each RSV. 

(5) Stockage level and loading times at each ASP/ATP. 

(6) Key RSV characteristics (ie. speed, RAM). 

(7) Reload times of each weapon. 

e. Output 

Output from the model consists of an audit trail 
of all events accumulated in a series of reports generated 
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through a subroutine called REPORT. The following is a list 
of output reports available: 

(1) Status of each HSV to include location and load. 

(2) Current ammunition status of each unit. 

(3) Status of each ATP/ASP to include number of MHE 
available, RSV's in queue and the amount of each type 
ammunition on-hand versus initial stockage. 

(4) An interdiction report to include which RSV's were 
interdicted and the type and amount of ammunition 
lost . 

(5) Emergency resupply information. 

f. Strengths 

The major strengths of ARM are: 

(1) ARM influences the gamer's tactical decisions for 
ammunition logistics by adding scenario generated 
constraints. 

(2) The model can be used to determine what transportation 
assets of the ASP/ATP are required to support a given 
scenario. 

(3) ARM models individual RSV's. 

(4) The model gives an indication of the capability of a 
given ammunition resupply system for a given scenario. 
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g. Weaknesses 

The principal weaknesses of ASM are: 

(1) ARM does not model the internal operations of the 
ASP/ATP in enough detail. 

(2) The model uses estimated straight line distances 
between firing unit and resupply points instead of 
actual road distances. 

(3) The model requires a manual data base development for 
each scenario. 

D. LOGISTICS MODEL DEVELOPMENT AT NPS 

The purpose of this section is to examine and discuss 
four previous NPS thesis efforts which modelled aspects of 
logistics. Three of these efforts are directly related to 
the STAR model. 

Since the development of the STAR model at NPS, 
logistics planners have been given a unique opportunity to 
investigate the dynamic interaction between the combat and 
the logistics process at the most critical juncture, the 
battlefield. Since its initial coding in 1978, the model 
has been continually expanded to include an ever widening 
horizon of combat functions. Although several attempts have 
been made to integrate logisitics into the model, little 
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logistics is currently played. This section will review 
several previous logistics theses written at NPS. Some 
address STAH directly; others do not. In summary, these 
works form part of the evolutionary development of logistics 
modelling at NPS of which this model is a part. Discussion 
of each effort will include: a general description; an 

enumeration of assumptions; a discussion of the modelling 
techniques developed; a discussion of strengths and 
weaknesses of these techniques; and an outline of the model 
utility. Some of the concepts developed in these efforts 
are used in this ammunition resupply model; others will be 
valuable for future efforts. 

1 . "S imulation a n d An al ys is o f Tr a nspor t in Support of 
a C omb at Unit " by John 5. Kelley (1978) r Kef . _3 ] 

This thesis parametrically analyzes the mission of 
the support platoon of a U.S. Tank Battalion. The stated 
objectives of the thesis were: to develop an overall 

logistics model that could be integrated into a battalion 
level combat simulation; to measure the Support Platoon’s 
ability to move supplies under varying conditions; and to 
evaluate the impact of simultaneous forces on combat support 
operations. 
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In pursuing these goals, a Monte Carlo simulation of 
the ammunition resupply process was developed. The use of a 
Monte Carlo simulation to capture the interaction of forces 
on the resupply process was a step away from traditional 
network/pipeline analysis normally developed for logistics 
studies. The technique involves the identification and 
isolation of significant variables within a process, 
assignment of probabilities of occurance to each variable, 
and replication of the process described by these variables 
in order to achieve an expected value outcome. Using this 
technique, the author was able to focus attention on 
specific aspects of the resupply process, to deliberately 
vary values for the probability of their occurance, and to 
statistically analyze results for significance, 
a. Assumptions 

The major assumptions made by Kelly in his 

thesis are: 

(1) The ability of a support platoon to provide ammunition 

support to the battalion is a direct function of: 

(a) The maximum number of trucks available at any time 
(Drivers assumed always available) . 

(b) The maintenance time required. 

(c) The probability of ambush. 
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(d) The probability of kill given an ambush. 

(e) The loss of vehicles to ambush. 

(f) The time required to replace lost vehicles. 

(2) Vehicles can make a maximum of three round trips a day 
to supply points. 

(3) Maintenance readiness is evaluted at the end of each 
trip. Readiness is measured against a fixed 
operationally ready (OR) rate. 

(4) Ammunition is obtained from a CSA located at the 
Division rear. 

(5) All vehicles in a convoy are subject to enemy attack. 
Survival of each vehicle is measured against a fixed 
probability of kill. Partial damage and salvage are 
not played. 

(6) Support is being provided to a "pure” tank battalion. 

(7) The effects of each of the parameters measured are 
independent and additive. 

(8) Measure of effectiveness selected: Truckloads moved 
during specified time periods. (3,5,15,30 days) 

b. Method of Evaluation 

Due to the software limitations on the analysis 
packages available when the thesis was written, the model 
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limited itself to a consideration of replacement time, 
probability of ambush, number of round trips delivered to 
supply points per day, and maximum number of vehicles 
available. Probability of kill given ambush, and 
probability of a vehicle becoming non-operat ionaily ready 
were fixed for each simulation run. The impact of these two 
factors was combined into the mean of the design. 

Having specified those aspects of the resupply 
process critical to the success of the Support Platoon 
mission, a range of probabilities for success for each of 
the critical parameters was fixed and a number of Monte 
Carlo simulations conducted for each variation. An analysis 
of the results was performed and an expected value for each 
set of selected probabilities was computed. The analysis 
conducted also measured the effects of each individual 
component, and its interaction with the ether elements. 

As a final demonstration of the methodology, a 
conflict set in a European scenario was developed and a 
simulation conducted. Values for each of the four critical 
parameters were varied in response to the scenario 
conditions, and in accordance with the judgement of the 
writer. A regression performed on the results fitted a 
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linear model to the data to check the linear fit of the 
postulated model. Parameters again were varied, results 
rallied, and tested for significance. 

c. Strengths 

The study achieved its objective of formulating 
and exercising a resupply simulation within the bounds of 
those parameters hypothesized as being critical. Accepting 
the premise that the factors modelled captured the critical 
essence of the resupply process, the technique used in the 
thesis could be modified and used in a generalized combat 
model to return a value of total tonnage of supplies 
delivered during a specified time period. 

The primary conclusion of the analysis 
conducted, that the probability of enemy attack and the 
physical location of the resupply point were the driving 
forces behind the model, dictates that such parameters be of 
prime importance to any resupply model. 

d. Weaknesses 

The major weaknesses found in the model are: 

(1) Conceptual limitation to those parameters defined as 
critical. Use of parameters other than those specified 
and tesred in the thesis would seriously weaken the 
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conclusions made in the thesis and could lead to 



incorrect results. 

(2) Current doctrine to include the creation and use of 
Ammunition Transfer Points (ATP's) was not considered. 

(3) Operationally Ready (OS) rates are normally determined 
on a daily basis rather than after each supply trip as 
proposed. 

e. Utility 

This model could best be utilized in the 
following manner: 

(1) The method developed and the results generated by the 
model would best be utilized as a generalized 
constraint to a high resolution combat model or, after 
some data analysis, as logistics coefficients in a 
Lanchester model. 

(2) The major finding of the model was that distance and 
probability of enemy activity were the driving 
parameters in the determination of overall mission 
accomplishment. As such, development of any resupply 
model should consider those parameters identified as 
critical in their structure. 
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2 . 



" S imu lat ion o f Ta ct ica l_Al te rnar ive R esp onses 11 by W . 

S. Wa ll ace and 3. G. Hagewo od (1 973) [ Ref ._4 ] 

This thesis and the follow-on work conducted by 
Wallace and Hagewood after their graduation from NPS formed 
the basis of what is now the STAR model. This original work 
was designed as a high resolution, event sequenced, 
stochastic model of ground combat. The language used was 
SIMSCRIPT II. 5. Since much of what was developed is still 
an integral part of the present model, this document is 
still a vital reference tool. In building the simulation, 
logistics effects were modelled in three ways. These were: 

(1) The use of logistics as an engagement constraint by 
asking the question, "Do I have this ammunition 
on-hand to fire?" 

(2) The use of logistics as a time constraint by asking 
the question, "Given that I have this ammunition on 
board the tank, what storage compartment is it in, how 
long will it take me to access it and move it to the 
ready rack?" 

(3) The modelling of logisitical methods to create supply 
caches in order to resupply combat elements. 
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Of rhese three attempts to model the effect of 
logistics on the combat process, only the first, logisitics 
as an engagement constraint is currently used. The use of 
logistics as a firing constraint was abandoned after the XM 1 
stowed load study was completed. This constraint could 
easily be added to the existing STAR model but at the 
present time such a high degree of resolution is 
inappropriate. The modelling of resupply caches was 
abandonned because at that stage of rhe model’s development, 
the contribution of the caches was of marginal value when 
weighted against the time required to prepare the data and 
the CPU time required to execute the logic. Tanks on the 
battlefield were killed, or the battle was ended before 
resupply was necessary and so the logic modelled became 
superfluous. 

Each of the three attempts zo incorporate logistics 
effects however, is worth analyzing in order to gain insight 
into the interplay of forces within STAR, and to gain 
modelling insight through access to existing working code, 
a. Methodology 

The general methodology of this model is as 

follows : 
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(1) Resupply As A Firing Constraint - in this logic, 

ammunition availability is played as a constraint to 
firing. The logic developed tracks on-hand ammunition 
by type for each tank. At the beginning of a firing 
sequence, a round is selected and its on-hand 
availability is screened on a go/no go basis. In 
implementation, ammunition is modelled at two critical 
junctures, when selecting the ammunition to fire, and 
upon round impact. The first juncture is controlled 
by routine PRIORITY . AND. ROUND. SELECT. This routine 
assesses the relative importance of the target 
currently selected, chooses a preferred round for use 
against the target, and checks to see if the stocks of 
the round are available. In performing this function, 
the routine accesses a matrix called a DANGER STATE 
array to determine the priority of the target, and to 
select the ammunition to be fired. Routine 
PRIORITY. AND, ROUND. SELECT then calls routine 
AMHO. CHECK which screens the ammunition attributes of 
the specific tank to determine if the ammunition is 
available. The second juncture occurs at the time the 
round is scheduled to impact. As part of the logic. 
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routine DECREMENT. AMMO is called to subtract one round 



of the type of ammunition fired from the tank which 
fired. 

(2) Resupply As A Limitation On Firing Time - the logic 
developed for this aspect of logistics was done in 
support of the XM1 tank stowed load study. It 
modelled the time reguired to physically move rounds 
inside an XM1 in an effort to add a degree of realism 
to the play by restricting the access to ammunition on 
the tank. This logic modelled the time reguired to 
move rounds from one of five storage compartments on 
the tank to the ready rack. This level of detail was 
later judged to be unnecessary in the normal use of 
the model. 

(3) Resupply - additional work after thesis completion 
attempted to extend ammunition concepts to include the 
movement of supplies from storage areas to resupply 
caches. The focus of this logic was a Supply Officer 
entity who controlled a number of caches in support of 
his unit. These caches are planned prior to program 
execution. In the execution, a routine PILE. SO. CREATE 
calls a number of subprograms which loads trucks at 
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the ATP (event LOAD. PLAN), moves loads to a 
pre-planned cache site (event MOVEOUT) , and offloads 
the ammunition at the site (event OFFLOAD). Resupply 
of the combat vehicles (event UPLOAD) was accomplished 
when the unit withdrew to the location of the cache, 
b. Strengths 

The major strengths of the model are: 

(1) Logistics As An Engagement Constraint - the logic 
developed directly tracks the on-hand balance of 6 
types of ammunition for each weapon system. This is a 
basic start point for any model that hopes to model 
logistics in STAR realistically. 

(2) Resupply As A Limitation To Firing - although this 
code proved to be of value in the XM1 stowed load 
study, the decision to turn off the code was more a 
function of lack of utility than absolute uselessness. 
The logic, in fact, provides an immediate tie-in for 
any future modelling of delivery of a resupply of 
rounds to the combat units. 

(3) Other logic developed depicts the loading and 
unloading of supply trucks and combat vehicles, 
creation of caches at pre-designat ed points, and a 
rudimentary stock control system. 
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Weaknesses 



c. 

The weaknesses of this model were perceived in 
the following areas: 

(1) There was no overall logic developed to dynamically 
control and integrate logistics play within the model. 
Tanks will continue to fire until ammunition stocks 
are exhausted. Resupply caches are entirely 
pre-programmed and once execution begins, the dynamic 
flow of the battle will not change the creation of 
stocks. 

(2) The assets possessed by a unit will not influence the 
ractical decision process. Logistics influence is 
limited strictly to fire/no fire control. 

d. Utility 

The SIMSCRIPT coding developed is fully and 
immediately integratable into STAR and thus represents an 
excellent start point for any new logistics study. The 
basic STAR model interface points still exist. If future 
STAR logistics modellers understand this logic they will 
save zhemselves considerable time and effort. 

The immediate extension of this logic includes 
recognition and use of the current ammunition status to 
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trigger resupply actions. Further extensions include the 
use of ammunition staxus xo modify tacxical courses of 
action or to trigger a request to move. 

3 • "A Dyna mic Amm unition and Resupp ly M o del in Suppo rt 

of the STAR Model” by B ruc e G. Ripley (1979) [Ref. 

5] 

This thesis presents a conceptual framework for 
modeling logistics functions within a combat brigade. The 
objective of the thesis was to develop a logical structure 
for the modelling of ammunition and fuel resupply. It was 
hoped that this logical structure would lay a basis for the 
future development of detailed logistics logic to be entered 
into STAR. 

The medium chosen to depict this framework was a 
network diagram. The primary product of the thesis was the 
development of this network and associated parameters 
essential to modelling resupply. Resolution of a fully 
developed model using this logic would depict individual 
trucks carring rounds of ammunition from the brigade trains 
to the combat vehicles. Ammunition would be measured by xhe 
"box”, a generic term used to represent all packaging 
configurations from the individual round to a pallet of 
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rounds. Petroleum would be measured in bulk terms only; 
packaged petroleum is not played, 
a. Assumptions 

The major assumptions made in this model are: 

(1) Battalion trains are located 5 Km and brigade trains 
are located 25 Km behind the PEBA. 

(2) Corps will transport ammunition from the Corps Storage 
Area (CSA) in the Corps Hear Area to the Ammunition 
Supply Points (ASP’s) located in the Division Rear and 
the Ammunition Transfer Points (ATP’s) located in each 
of the brigade areas. 

(3) Corps ammunition support to the division will be 
provided by two conventional ammunition companies with 
each company operating two ASP's. 

(4) Capabilities of ammunition points are as follows: 

(a) ASP - Receipt and issue of 2000 short tens of 
ammunition daily. 

(b) ATP - Receipt and issue of 500-500 short tons of 
ammunition daily. 

(5) Only 5 ton trucks are capable of making the round trip 
from the battalion trains to an ASP and back. AFARV's 
and GOER'S are limited to trips to/from the ATP's at 
brigade. 
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(6) Vehicles will travel only in convoys. 

(7) Operationally ready rates (OR) are computed once daily 
according to the following rates: 

(a) Material Handling Equipment (HHE) - 75% 

(b) Bn Ammo Vehicles - 85% 
b. Characteristics 

The resupply framework was developed around the 
traditional supply MOE of ascertaining the number of 
truckloads of ammunition delivered per unit time. In 
execution, the network traces the movement of trucks of 
varying dimensions through a network subject to uniformly 
distributed movement and loading times. 

(1) Network Development - the key to the thesis work was 
the development of the network diagram itself. The 
network depicts the flow of supplies from division and 
brigade storage areas to the battalion trains. 

Central to this concept was the determination of the 
number and characteristics of carriers, arcs, and 
nodes which make up the system. 

(a) Carrier: the term used to represent the actual 
supply trucks on the network. Each carrier type 
has specific weight and cube limitations. These 
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limitations are used to constrain a vehicle’s 



capability to transport ammunition. The carrier 
is the critical focus of the system, since 
determination of the quantity delivered per unit 
time is based on the carrier's successful 
completion of trips tc/from the supply points. 

(b) Arc: the term used to represent road segments on 
the ground. Arcs direct traffic flew and are used 
to determine straight line travel time between 
points. Load capacity of roads is depicted by 
limitations on vehicle speeds on individual arcs, 
for example, 10 mph over unimproved roads. Road 
congestion, although identified as potentially a 
major problem, was not explicitly modelled. 

(c) Nodes: these mark points of change within the 
network itself. Two types of nodes were specified, 
load state changes and travel state changes. Load 
state changes mark those locations where 
ammunition is loaded and unloaded. Activity at 
these points is modelled as time delays generated 
from specified distributions. Operationally, these 
delays would be modelled as a function of the 
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number of people at the point, the number of MH£ 
pieces ax the point, the capacity of the carrier, 
and the length of the gueue at the resupply 
location. Travel state changes represent those 
points on the network at which direction of travel 
changes. These points represent travel through 
cities, past major intersections, and through 
points of congestion. 

(2) Movement And Load Times - a second key aspecx of this 
framework is the concept of time use. All times 
within the model are assumed to be uniformly 
distributed about a calculated mean. Thus travel time 
along a stretch of highway is based on the length of 
the roadway and on the assumed speed of the vehicle. 

To this, an induced variability of plus or minus 203 
was introduced to allow some further randomization of 
vehicle times. Load/unload times were based on an 
assumed loading time for the particular load on a 
specific cargo carrier. Thus, ammunition cargo varied 
by the "box" configuration to be handled, while fuel 
loading varied in accordance with the load capacity of 
the pump assumed to be at the location. 
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c. Strengths 

The strong points of this model are: 

(1) The thesis successfully established a network diagram 
which adequately captures the various activities which 
make up the supply chain. The example illustrated in 
the thesis is in generalized enough terms to be easily 
adaptable to any particular setup. 

(2) Although designed for a FORTRAN simulation, the 
descriptors used to model the flow of the network can 
be adapted to any simulation language. These critical 
descriptors and the information they convey are as 
follows: 

(a) Arcs: length of road segment; type of road 
(unimproved , etc. ) ; average vehicle speed on the 
road; amount of congestion on the road. 

(b) Nodes: type (road junction, supply point , town , etc) ; 
average delay time expected. 

(c) Carriers: 

• Ammunition Carriers - type, max cargo 
weight, operationally ready status; location; 
amount of cargo on board; type of cargo on board; 
unit. 



55 



• Petroleum Carriers - type; fuel carried; 
amount carried; gallon capacity; pump rate. 

(d) "BOX” of Ammo: weight of package; volume of 
package; number of rounds/box. 
d. Weaknesses 

Some of the major weaknesses perceived by the 
authors in the model are: 

(1) In briefly outlining assumptions, locations of support 
units were discussed in terms of fixed distances 
rather than as envisioned in the more flexible design 
doctrine called for. In fact, present doctrine calls 
for the battalion trains to normally divide assets 
between two locations, the combat trains and the field 
trains. Combat trains are located 5-7 Km behind the 
FEBA while the field trains are located 10-15 Km 
behind the FEBA. The composition of either is 
flexible; however, the bulk of ammunition supplies is 
normally maintained at the field trains. Brigade 
trains are normally located 15-25 Km behind the FEBA 
and so could conceivably be co-located with the 
battalion trains. The central considerations which 
dictate the location of these facilities is the 
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mission of the unit and the range of enemy medium 
artillery . 

(2) The vehicle load times for various ammunition types 
were established for illustrative purposes. More 
realistic distributions must be developed for actual 
applications. 

(3) No provisions were made to model hostile action on the 
network. 

(4) No queue was explicitly established at any supply 
point. 

(5) The network was self-contained and designed to model 
only the movement of battalion trucks on the network. 

(6) Once a resupply vehicle arrived at the battalion 
trains, resupply was considered completed. No attempt 
was made to model the loading of ammunition on combat 
vehicles. 

(7) There was no decision logic developed to dynamically 
control the network or to react to a change command 
once the vehicles were set in motion. 

e. Utility 

The network designed is an excellent starting 
point for the development of resupply logic at the 
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battalion/brigade level. The detailed development of the 
essential elements of this network is a first cut at molding 
the disparate elements of resupply into a coherent process. 

4 • M A High Resol uti on Integrated Com b at and Logisti cs 
Mo del 11 by D . G . Kirby and D. P. Schultz (1 980) f Ref. 

6 ] 

This thesis was the first attempt to integrate the 
effect of logistics in the STAR model. The objective of the 
work was to design a broad flowchart of the programming 
logic required to model logistics and to investigate a means 
of modelling the command and control decision processes 
which overlay this process. The authors limited their 
discussion to the resupply of petroleum and ammunition. In 
depicting this development, the authors utilized the 
Software Decision and Documentation Language (SDDL) which 
outlines the logic of the program in the form of a detailed 
flowchart. 

a. Assumptions 

The major assumptions made by Kirby and Schultz 



are: 



(1) The Battalion Support Platoon is solely responsible 
for battalion resupply. Ammunition is obtained from 
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either the AT? run by DISCOM, or from the ASP run by 
corps. Petroleum is obtained from DISCOW tankers 
spotted in the Brigade Supply Area. 

(2) Resupply can be accomplished either by moving supplies 
forward to the combat vehicles (unit resupply) , or by 
pre- posit ioning ammunition at specified locations 
(Cache) . 

(3) Supply vehicles carry homogeneous loads. No 
cross-leveling of cargo between supply trucks is 
permitted. 

(4) Ammunition will not be redistributed between elements 
of a unit. 

b. Methodology 

The logic designed can be divided into three 

categories : 

(1) Command logic within a battalion. 

(2) Unit resupply logic. 

(3) Supply point resupply logic. 

The critical development by the authors was the 
design of the command decision logic; flow for the other two 
categories was relatively transparent. Command logic is used 
primarily to evaluate the current supply situation and to 
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determine a priority for resupply. The key tc this logic 
lies in the development of the concept of Level of Need 
(LON) . 

Level of Need (LON) is a categorical structure 
through which the resupply situation of a unit is expressed. 
It represents the ratio of supplies on-hand to the total 
capacity of the unit. The authors define four Levels of 
Need; full, want, approaching critical, and critical. LON 
is computed for each firing system with regard to its 
primary ammunition and its fuel status only. The lowest 
category computed for either determines the overall LON for 
the weapon system. At the platoon, this logic models the 
platoon leader examining the LON of each of his vehicles. 

The platoon is then assigned an LON based on the category it 
falls under. This platoon logic is duplicated at each 
company, battalion, and brigade in the resupply chain 
thereafter. 

Decision logic for resupply uses this LON and 
combines it with a consideration of supplies available for 
issue and an evaluation of the suppression level at the unit 
being resupplied. A listing of all requests is then 
prioritized in accordance with the above criteria. Ties are 
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broken in favor of the unit with me greatest number of 
weapon systems alive, the thought being that maximization of 
available combat power is a commanders first concern. 

c. Strengths 

The thesis clearly outlines those essentials 
necessary for the modelling of resupply. Although no code 
was developed, the flow diagram developed illuminates the 
path to be taken. Decision logic is always a difficult area 
to model. Development by the authors of a conceptual basis 
for this process is invaluable. By specifying the urgency of 
need through the concept of LON the authors made the 
resupply decision logic workable. This procedure for 
prioritizing resupply efforts based on the factors 
enumerated outlines a clear and realistic model of the 
commander’s thought process. 

d. Weaknesses 

Presentation of a combined LON depicting the 
fuel and ammunition situation is unrealistic. The need for 
ammunition and fuel must be assessed separately as each 
impacts on the tactical situation in a different manner. In 
fact, a further sub-division within these categories as to 
type of fuel and type of ammunition would present a clearer 
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and more realistic picture upon which to base tactical 
decisions. The method of combining LON at platoon and above 
based on a predominant LON and on a subjective assessment of 
the relative importance of tactical systems is also 
unrealistic. Again a sub-division of information into types 
of ammunition and types of fuel needed would add a clearer 
and more realistic dimension to the problem play. Failure 
of the authors to develop logic for the redistribution of 
on-hand assets is unrealistic. Addition of such logic would 
present a truer picture of the real process within units. 
Lastly, consolidation of ammunition on-hand at the platoon 
level and above must include a consolidated count of all 
assets on-hand, including reserve assets. Failure to do 
this would again cause decisions to be based on unrealistic 
data. 

e. Utility 

This thesis illuminates the path of development 
for future logistic modelling in STAR. The flowcharts 
presented are detailed and thorough. They totally explain 
the resupply network. This concept of modelling the 
decision framework overlaying the supply network, while 
needing significant revisions, steers future efforts in the 
right direction. 
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Ill . MODEL DESCR IPT ION 



A. INTRODUCTION 

This chapter presents an overview of the ammunition 
resupply model developed for this thesis. It discusses each 
of its parts in general terms and lists its major 
assumptions. A detailed discussion of the model, to include 
an explanation of the SIMSCRIPT II. 5 programming language 
and the model code developed is presented in Appendicies A 
and B. 

The resupply model presented in this thesis is a 
stochastic, discrete-event simulation implemented in the 
SIMSCRIPT II. 5 programming language depicting ammunition 
resupply procedures within a combat battalion. The basic 
structure of the ammunition support flow is taken from Army 
Field Manual 9-6, Amm u niti on Service i n th e T hea t re of 
Ope rati ons [Ref. 7]. The model is designed to provide a 
flexible framework within which the user may specify the 
Tables of Organization and Eguipment to be played and the 
critical resupply levels which will result in a resupply 
action. In its present form the model can play an unlimited 
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number of weapon systems and ammunition types, however, each 
individual system is limited to a maximum of 6 ammunition 
types. 

Section 3 of this chapter discusses the battle used in 
generating the data for the model. 

Section C explains how ammunition expenditures are 
tracked from the weapon to battalion and how such 
expenditures thereby trigger resupply action by the chain of 
command. 

Section D discusses the resupply logic used at each 
level of command in evaluating the availability of on-hand 
ammunition and determining both the guantities released and 
priority of resupply. 

Section E explains how the redistribution of on-nand 
ammunition assets is modelled and when it takes place. 

3. THE BATTLE 

The purpose of the battle in this model is to generate 
requirements than will force a response from the ammunition 
resupply logic developed. Initially, the authors intended 
to use the STAR model as a source for input data, since a 
record of ammunition expenditures is normally generated as 
part of its output. In the present configuration of STAR, 
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however, the battle terminates well before ammunition 
resupply ever becomes critical, so a direct tie-in to the 
model was deemed impractical. An alternate proposal for 
generating data from multiple STAR runs was also rejected as 
too cumbersome. 

Instead, it was decided to generate the needed data 
through the use of Lanchester eguations and Hcnte Carlo 
techniques. Admittedly, considerable realism and resolution 
are lost in doing this, but the simplification permits the 
generation of necessary data without the use of a 
prohibitive amount of computer time exercising the STAR 
model. It is important to keep in mind throughout the model 
rhat the battle generated is unrealistic and is used solely 
as an expedient to generate data for the logistics model. 

Examples of the types of data generated by the battle 
for use in the resupply model are: 

• Ammunition Expenditures Over A Given Time Period - this 
data is generated for each weapon system in the battle 
and each ammunition type it might possess. 

• Damaged And Destroyed Vehicles - combat and resupply 
vehicles are periodically checked for battle damage by 
evaluating random number draws against a set of damage 
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probabilities assigned by the user to each type of blue 
vehicle in the model. 

• Movement Of Units - within the present model movement of 
company units is accomplished on a random basis. The 
purpose of such moves is solely to execute the model's 
redistribution logic. 

The major assumptions underpinning the battle's 
architecture are: 

• Battles are fought for 6 hours a day. The start time of 
the battle is determined by a random draw. 

• Each weapon type of a weapon system has a rate of fire 
assigned through user input. However, the same weapon 
on a different system can be assigned a different rate 
of fire if the user so desires. 

• Ammunition expenditures are generated in the model by 
evaluating random number draws against weapon system 
probabilities of fire for each armament. Expenditures 
are then computed by multiplying the rate of fire for 
that armament times the elapsed battle time for that 
particular day. 

• Combat vehicle damage is assigned on a random basis over 
four types of kills : firepower kills, mobility kills. 
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mobility/firepower kills, and catastrophic kills. For 
all types of damage except firepower kills, ammunition 
on board that vehicle is considered lost. Ammunition 
assets belonging to a vehicle that sustains a firepower 
kill are assumed undamaged, and are immediately 
redistributed to the other fighting vehicles within that 
fighting system’s respective platoon. 

• Movement is restricted to company units and can take 
place only after that day’s battle. 

C. REQUESTS FOR RESUPPLY 

Expenditures of ammunition by individual weapons form 
the basis of resupply activity in the model. Key to this 
process is a concept called level of need (LON) . A level of 
need is evaluated for each ammunition carried by a combat 
entity in the simulation. These individual vehicle LON's 
are aggregated to form LON’s for each platoon and company in 
the model. The purpose of the LON is to provide a measure 
of the urgency of need a weapon or unit has for a particular 
ammunition type. An entity’s LON is updated over uniformly 
distributed time intervals independently of other vehicles 
or units in the model. This technique was implemented in 
order to capture some sense of the imperfect information 
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•that is inevitably generated and passed in any supply 
system. The purpose of this section is to explain this 
resupply request process and to discuss the effect of and 
reaction to the imperfect information by the chain of 
command. 

1 • Level o f Ne ed (LON) 

Level of need is a concept that was originally 
developed by Kirby and Schultz in March of 1980. The basic 
idea they developed is adopted for use in this model with 
some major alterations. The concept of a level of need was 
adopted because it represents a single unifying idea that 
will allow the expansion of this model to all classes of 
supply. 

Level of need describes the urgency of need a weapon 
has for a particular type of ammunition. This urgency is 
then sequentially passed to and evaluated at each level in 
the chain of command until a level is reached which can 
respond appropriately. A separate LON is computed for an 
ammunition type at the weapon, platoon, company, and so on 
with information from each lower level being fed into the 
computation of the LON of its immediate superior. In 
effect, this forces each level to respond to the battle 
flow. 
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The actual value for an LON is assigned based on the 
measured percentage of fill (amount on-hand / base load) of 
an ammunition type at a particular moment. The essential 
idea is to have threshold values for the percent fill of an 
ammunition type which will trigger a leader's actions. The 
benchmark for this computation is called a base load for 
that ammunition type. An LON continually changes as 
individual weapon entities, each with its own ammunition 
configuration, are damaged or destroyed. 

At the weapon level, base load is equal to the 
initial stowed load for the particular ammunition in the 
weapon system. This load can be different fox each weapon 
system within a platoon. An ammunition's base load, for a 
platoon, is equal to the sum of all stowed loads of alive 
systems in the platoon possessing that ammunition type. A 
company's base load is, in turn, determined by summing over 
the base loads within its platoons and so forth. 

Level of need within the model is divided into 5 
categories, the thresholds of which are controlled by user 
input. These 5 categories are defined as follows: 

a. Full ("5") - a weapon or unit has enough of its base 
load of an ammunition on-hand that no resupply is 
warranted for that ammunition type. 
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b. Want ("4") - the weapon or unit's on-hand load is below 

full, but is not in a position to jeopardize the 
mission. Reaching a "WANT" LON initiates a resupply 
action at the lowest priority. 

c. Approaching Critical ("3") - this level implies that 
the weapon or unit's on-hand ammunition is at a level 
warranting a higher urgency of need for resupply and a 
greater priority for fill when ammunition becomes 
available than the "WANT" level. 

d. Critical ("2") - the weapon or unit's on-hand 
ammunition has reached a level that seriously endangers 
mission accomplishment to the point that survival of 
the weapon or unit may become a problem. Immediate 
action is essential. 

e. Empty ("1") - the weapon or unit has no on-hand balance 
for a particular ammunition type and is no longer able 
to perform its mission. 

Weapon and unit LON thresholds for the above 
categories are left as user inputs and must be supplied by 
the user for each combination of ammunition type and level 
of command. A tank then has different threshold values for 
the several ammunition types it carries. This corresponds 
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to placing degrees of importance on types of ammunition. 

So, while a tank might be considered critical for APDS 
rounds when it reaches 30? of its stowed load, it might not 
become critical for 50 caliber ammunition until it reached 
10? of its stowed load. At the platoon, the threshold 
values for these same ammunition types would be different 
from those of the individual fighting systems. This models 
a platoon leader's wider perspective on a battle situation. 
This situation is repeated at successively higher levels of 
command. 

2 . Reques t s for Resupply 

The resupply process begins at the weapon system 
where ammunition status is periodically updated. The time 
between updates is determined based on draw from a user 
defined probability distribution. The platoon, for its 
part, periodically updates its own status by obtaining 
information from each of its assigned weapon types. The 
company, in turn, updates its status by obtaining 
information from each of its platoons. The information 
"passed" to each level is that obtained from each entity's 
most current update rather than from any source of "perfect" 
information. Requests for resupply below company level are 
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limited to those ammunition types for which a vehicle or 
platoon is empty. These requests alert the next higher 
level to update its ammunition situation and to take action 
appropriate to its level. 

The formality of a resupply requisition is 
introduced at company level where resupply requests from the 
company to battalion are triggered every time a company's 
LON changes for an ammunition type. Quantities requested 
vary in accordance with the assets possessed by the 
requesting entity. 

3 . Imper fe ct L ogi stics Inf orm ation 

Information passed during a battle is approximate at 
best. The imperfect nature of this information is a result 
of many factors, including: 

a. Estimates of on-hand ammunition made at the weapon 
during combat - It is frequently impossible to stop and 
count ammunition assets during the heat of an 
engagement; educated guesses are often the rule rather 
than the exception when passing ammunition information. 

b. Time lapses between resupply requests and delivery of 
requested material - from the time the request is 
forwarded until the delivery of the ammunition. 
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additional resources will be expended and weapon 
systems lost. 

c. Simple counting mistakes. 

Within the model, imperfection of the logistics 
nformation is induced as follows: 

• Weapon systems update their ammunition LONs periodically 
at random times within user established minimum and 
maximum times. ' Upon request from platoon, the weapon 
system provides its most current count; that is, it 
provides the information obtained from its own last 
ammunition update. 

• Platoons and companies can obtain their information only 
from their immediate subordinates, again at random times 
within user specified intervals. This procedure 
duplicates the periodic requests for ammunition updates 
from platoons and companies to their subordinates during 
a battle. Again, the information reported by each 
subordinate level is that obtained from its own last 
update . 

• At the company level, formal resupply requests are 
created by ammunition rype as an ammunition's LON value 
changes. This corresponds to a company periodically 
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reviewing and updating its resupply requests because of 
ammunition expenditures or loss of ammunition due to 
vehicle damage or destruction. The quantity requested 
each time is the quantity which would be required to 
bring a unit back to full base load. At the supply 
unit, upon receipt of a new resupply request, this new 
requisition is filed, and any older requests for that 
ammunition and that company are destroyed. 

It is important to note that in both a and b above 
the modelling techniques described give the user the 
flexibility to make the logistics information flow as 
accurate or inaccurate as desired by controlling the 
randomness of the LON updates. 

4 . As su m ption s 

The major assumptions made during the resupply 
request process are: 

a. Requests for resupply are an iterative process up the 
chain of command with each level receiving information 
only from its immediate subordinates. 

b. An LON of empty ("I") initiates an immediate request 
for action up the chain of command. 
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c. Formal resupply requests from the company are triggered 
by charges in an ammunition LON. The acrual quantities 
of ammunition used to calculate the LON's are available 
at each level of command so that resupply can be 
affected at that level if appropriate. 

D. R2SUPPLY 

The resupply process begins with the receipt of a 
resupply request by the Battalion S-4. This receipt 
initiates a sequence of events which ultimately results in 
rounds being placed on the weapon system itself. This 
section explains how resupply of requested ammunition is 
accomplished. The explanation includes modelling the 
Battalion S-4's decision logic; the resupply logic of the 
company after assets are received from battalion; and the 
distribution decision logic of the platoon leader after a 
resupply is received from the company. The explanations are 
general in nature. A detailed discussion of the logic is 
contained in Appendix A, Section D. 

1 . Battali on Di st ribu tion 

A battalion's initial reserve of ammunition is 
determined by the number and type of resupply vehicles 
(RSVs) in the support platoon and the type and amount of 
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ammunition those vehicles are designated to carry. This 
information is determined by the user and entered as input. 
An RS7 ' s hauling capability for an ammunition type is 
determined by its cube or weight limitations, whichever is 
reached first. 

Within a battalion, the S-4 is responsible for 
controlling the distribution of battalion reserve ammunition 
assets to subordinate companies. The S-4*s responsibilities 
include the following: 

a. Review and prioritization of requests filed by priority 
and time of request. The most critical LONs ("I") are 
filled first. If there is more than one, the requests 
are filled in the order they were received. 

b. Determination of the number of RSV's necessary and 
available for resupply missions. 

c. Determination of the proper mix of ammunition types to 
be delivered to a unit in the face of multiple requests 
and limited transportation. 

2 . Company Distr i but ion 

Upon the arrival of a resupply convoy, a Company 
Commander takes the following actions: 
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a. Determines the type and quantity ox the ammunition he 
has received. 

b. Determines the immediate needs of the platoons in the 
company . 

c. Distributes the ammunition received to each platoon in 
amounts dictated by their immediate urgency of need. 

d. Se-evaluates the company's levels of need. 

3 • Plato on Distr i bu tion 

The Platoon Leader's responsibilities for the 
distribution of ammunition resupply to the weapons within 
the platoon are the same as those of the Company Commander. 

4 • Assu m ptions 

The major assumptions made in developing logic to 
model a battalion's ammunition resupply distribution process 
are: 

a. When a resupply action is triggered at battalion, the 
S-4 responds only to those requests he has knowledge of 
and then only in the amounts listed on that request. 

No further update is permitted until a new request is 
received. 

b. RSVs will not be dispatched from the battalion trains 
with less then a half load of ammunition unless the 
load contains ammunition with an LON of "I". 
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c. RSV's can carry loads of mixed ammunition but only to 



one company. 

d. RSV’s resupplying the same unit will travel in convoy. 

e. If an RSV is damaged or destroyed all the ammunition it 
is carrying is assumed to be destroyed. The ammunition 
is not replaced during the simulation run. 

f. RSV's that complete a resupply mission arrive back at 
the battalion trains with the same load they delivered 
after an appropriate time delay. This simulates the 
RSV's round trip to an ASP/ATP and permits restocking 
of battalion ammuniton assets. 

g. Ammunition stockage at the battalion trains is limited 
to the total weight and cube limitations of the 
battalion ammunition trucks earmarked to haul it. 
Individual RSV loads are not "fixed" but rather remain 
flexible, subject only to the stockage at the trains 
and the weight and cube restrictions of the vehicle 
itself . 

h. An ATP/ASP has unlimited supplies of all ammunition 
types. The only limiting factor on the amount of 
ammunition an RSV takes back to its battalion trains is 
the vehicle's own weight and cube limitation. 
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REDISTRIBUTION 



n . 

In an actual combat situation redistribution of on-hand 
ammunition assets is performed as standard procedure in 
certain situations. This section describes the situations 
which warrant redistribution in this model. It explains 
when and where the redistributions occur and the major 
assumptions made in performing them. 

1 . Re dis tr ibut ion D ue To R elo c atio n 

Redistribution takes place immediately upon 
completion of any unit move. This activity is accomplished 
within platoons only, with its objective being the even 
redistribution of all on-hand assets. In the model, the 
following actions take place when a move is completed: 

a. All weapons give their respective platoons an 
ammunition update. 

b. Each ammunition type is divided evenly among weapons 
using it with respect to the weapon's stowed load. 

2 • Redistributio n Due To .A . Firepo wer Kill 

Redistribution of on-hand assets is performed in the 
event of a vehicle sustaining an F-kill. In this case, the 
platoon redistributes the ammunition as if it has just 
received a resupply egual to the ammunition on the F-killed 
vehicle. 
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3 . 



As sumpt ions 

The major assumptions made during a redistribution 

are : 

a. Redistributions only take place at the platoon level. 

b. A vehicle receiving an F-kill becomes an RSV until all 
on-hand ammunition is distributed. 
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IV. 



CONCLUDING RE MAR KS AND FUTURE ENH ANCE a ENT S 

A. GENERAL 

This ammunition resupply model represents the first step 
toward the eventual development of a low level, high 
resolution logisitics model designed to interface directly 
with a comparable combat model. Program logic thus far 
developed explicitly depicts current U.S. Army supply 
doctrine at the battalion level. Beginning with the 
individual firer, the model simulates the ammunition 
resupply network responding to identified needs and 
ultimately providing the appropriate ammunition to weapon 
systems. 

In executing this process, the model performs the 
following functions: recognition of shortages at all levels; 
initiation of requests for resupply appropriate to the level 
of command; determination of quantities to be released to 
fill requests; and delivery of supplies down to the weapon 
systems. The authors have tried to keep the model as 
flexible as possible by designing it in a manner that lets 
the user assign values at input for the critical variables 
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of the resupply process. The remainder of thxs chapter is 
used to lay the foundations for continued work based on the 
ideas developed in this thesis. The approach taken in 
outlining the direction of future efforts is threefold: to 
explicitly highlight some of the model's major deficiencies; 
to discuss several possible development paths which might be 
taken in expanding the model; and to discuss adjustments 
necessary to integrate this model with a comparable low 
level, high resolution battalion combat model. 

B. MODEL DEFICIENCIES 

Fundamental to understanding what a model can do is the 
equally important issue of knowing what a model cannot do. 
This model is deficient in the following areas: 

1. Battlefield Realism - Due to the simplified nature of 
the battle, combat processes are not well played. 

Basic forms of maneuver, elementary command decisions, 
and individual combat action are not modelled beyond 
the simplest levels. These activities have a 
significant impact on the supply system and represent a 
critical deficiency in this model. 

2. Damage Assessment - The simplified damage assessment 
routine, limited to combat weapon systems only, was 
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developed solely to drive the resupply logic. 

Extension of this damage logic to resupply vehicles, 
development of a maintenance recovery and repair 
capability, and an ability within the supply system to 
respond to item losses would be a significant gain. 

3. Movement - The model does not depict movement beyond 
the imposition of a simple time delay for travel from 
one section of the battlefield to another. These 
delays are based on doctrinal distances and do not not 
consider terrain, weather, or suppression. The 
addition of terrain and movement modules would add a 
significant dimension to the model and permit the 
extension of logic into related resupply issues such as 
route selection, traffic control, and traffic 
congest ion . 

4. Resupply Logic 

a. The battalion played in the model is always 

resupplied, after a time delay, with the exact type 
and quantity of ammunition it has released to its 
companies. The source of this resupply is an 
ATP/ASP that contains unlimited ammunition assets. 
These assumptions significantly reduce the realism 
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of the model and should be amended to include, at a 
minimum, a limit on the resupply available to a 
battalion dictated by the prevailing Command Supply 
Rafe(CSR) and Required Supply Rate(RSR). 
b. Convoys in the model are limited to point to point 
delivery of ammunition. Multiple deliveries by one 
convoy to several companies is not allowed. This 
deficiency decreases the model's realism by limiting 
a battalion's ability to efficiently use its 
transportation assets, and a company's ability to 
control these assets when a convey arrives. 

C. PATH OF FUTURE DEVELOPMENT 

Having initiated a basic structure for the resupply 
model, expansion paths for resupply logic, both within the 
confines of the battalion model itself, and beyond the 
battalion supply point to brigade have become apparent. The 
expansion ideas mentioned in this section will be limited to 
those areas of improvement within the supply system itself, 
purposely disregarding issues directed at the model's 
interface with a high resolution combat model. Some of the 
points mentioned in this section have been identified as 
model deficiencies but are re-mentioned here for emphasis. 
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Expansion of this model, with respect to resupply logic, is 
needed in the following areas: 

1. Development of logic to mere realistically depict the 
transport of ammunition from the ATF/ASP to the 
battalion trains. Such logic should include the 
explicit modelling of supply routes and the traffic 
control points overseeing these routes. 

2. The effect of enemy interdiction efforts on the rear 

area supply points. 

3. Development of a routine to extend the possibility of 

damage to resupply vehicles and convoys. 

4. Development of routines to model maintenance, recovery, 

and repair as well as replacement of damaged systems. 

5. Extension of delivery logic to allow resupply vehicles 

and convoys the option of delivering to more than one 
company . 

6. Addition of movement and terrain logic. 

7. Improvement of the redistribution logic to include 

provisions for an emergency resupply of ammunition if 
a situation warrants it. 

8. Explicit representation of activities at the ATP/ASP to 

include queue and service times for trucks, and 
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ATP/ASP interface procedures. As mentioned in Chapter 
2, much of this logic has already been modelled in 
HELAP5 II . 

9. The imposition of a Command Supply Sate (CSR) and 

Required Supply Rate (RSS) as a driver for the entire 
resupply process. 

D. INTEGRATION INTO A COMBAT MODEL 

Integration of this model into a low level, high 
resolution combat model presents the following problems: 
the problem of interfacing independently developed program 
logic; the necessity of developing additional command and 
control logic to blend the two models together; and the need 
to adjust the tactical decision making process to include 
the effects of logistics. Each of these issues is discussed 
separately below. 

The problems of merging an independently developed 
resupply program into a fully developed combat model were 
recognized and carefully considered in the development of 
this ammunition resupply model. To overcome these problems, 
the model was developed as a self-contained module. The 
foreseeable interface problems with a combat model are thus 
limited to insuring that: the combat model captures 
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ammunition expenditures and passes them to the resupply 
logic; the resupply model has movement logic that interfaces 
with the movement logic of t-he combat model; and the supply 
model's resupply routines interface with the weapon systems 
of the combat model when delivering ammunition. Since the 
model developed in this thesis was specifically designed to 
interface with the STAR model, these changes would be 
limited to: the addition of several attributes to the chain 
of command structure; the addition of several attributes to 
the weapon systems; and the integration of convoy movement 
with the STAR movement logic. 

Perhaps the greatest change caused by the addition of a 
resupply module would be its effect on the command and 
control logic of the combat model. A combat model's 
decision process could be expanded to include at least the 
two most basic methods of resupply for a battalion, unit and 
cache. Consideration of the^e two methods would necessitate 
development of logic which could dynamically answer the 
following questions: 

1. Who has priority of resupply? 

2. What ammunition is to be released subject to what 
command restrictions? 
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3. How will resupply be accomplished? Will supply 
personnel be present with any type of equipment? 

4. Where will the resupply be accomplished? At the current 
location? At a subsequent position? At a rendezvous 
point? 

Lastly, combat decisions are inevitably influenced by 
the availability or nonavailability of resupply. Inclusion 
of resupply logic into a combat model would force an active 
consideration of resupply issues in making the following 
tactical decisions: 

a. Adjusting rates of fire. 

b. Changing a weapon's primary ammunition of 
engagement . 

c. Decreasing or increasing a weapon's range of 
detection and engagement. 

d. Movement to alternate positions or the withdrawal of 
a unit. 
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APPENDIX_A 

DETAILED METHODOL OGY OF THE MODEL 

A. INTRODUCTION 

This appendix gives a detailed description of the 
ammunition resupply model in a format suitable for use by 
programmers and analysts. The discussion in this appendix 
approaches the model from a broad perspective in order to 
show the effect of the techniques used to model the "real 
world" resupply process. Prior to discussing the 
methodology itself, a brief description of the SIMSCRIPT 
II. 5 programming language used in the model is provided for 
readers unfamiliar with the language. A detailed 
explanation of the actual code developed is provided in 
Appendix B. 

B. USE OF SIMSCRIPT II. 5 IN THE MODEL 

The SIMSCRIPT II. 5 programming language is designed to 
model discrete-event simulations. It is a user friendly 
language with a structure very similar to everyday speech. 
This feature enables a reader to quickly grasp and follow 
the flow of any program. Beyond the narrative clarity. 
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SIMSC3IPT provides an organizational structure which extends 
a programmers conceptual horizon beyond the normal bounds 
imposed by the use of variables and arrays. Central to this 
structure are the key ideas of entities, attributes, and 
sets. 

3ntities are program elements whose characteristics are 
being modelled in the simulation. In the ammunition 
resupply model for example, tanks, platoon leaders, company 
commanders and supply officers are classes of entities in 
the system. Attributes are discriptors which depict the 
entity's characteristics. In the model, every platoon 
leader entity carries attributes which define his unique 
company commander. Thus, although all entities in the same 
class have the same attribute names, they can be 
distinguished from each other by the values of their 
attributes. Attributes may have real, integer, or 
alphanumeric values. 

A set is a collection of entities possessing some common 
property. The ammunition resupply model uses sets to track 
the type and amount of ammunition on-hand in each platoon. 
This is done by creating an entity for each type of 
ammunition with attributes which record the quantity 
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required and actually on-hand. Each entity is then filed in 
a platoon's ammunition set and its attributes thereafter 
track only that platoon's ammunition status. 

An event in SIMSCRIPT is an occurrence which takes place 
at a specific simulated time. Events can change the values 
of entity attributes, remove or add entities to sets, create 
or destroy entities, or schedule other events to take place 
at later times. In the model, a weapon which expends all of 
its ammunition keys an event which notifies the platoon 
leader and starts decision logic for resupply. Events rake 
place instantaneously and do not consume simulated time. 

The use of SIMSCRIPT II. 5 greatly simplifies the 
tracking of ammunition expenditures throughout the chain of 
command. The actual set, entity, and attribute structure 
used in this model is explained in detail in Appendix B. 

C. GENERAL MODEL METHODOLOGY 

The ammunition resupply model developed for this thesis 
is a stochastic discrete-event simulation designed to 
portray ammunition resupply procedures within a O.S. combat 
battalion. The model is a stand-alone, closed loop process 
which simulates the following activities within a combat 
battalion: periodic updating of individual weapon and unit 
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ammunition status; recognition of the need for and 
submission of requests for resupply; and receipt and issue 
of supplies from battalion reserve stocks. The overall 
process modelled is depicted in Figure 2 below. 




Figure 2; Resupply Process 



The fundamental process depicted in the figure is duplicated 
at all levels of command (weapon, platoon, company, and 
battalion) , differing only in the response options available 
at each level. 

D. INPUT REQUIREMENTS AND THE INITIALIZATION OF DATA ARRAYS 
Input to the model is used to accomplish the following; 
the creation of entities played in the simulation; the 
establishment of chain of command relationships between 
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entities; the scheduling of initial ammunition update times; 
and the establishment of parameter values for supply action 
and response {LON Thresholds). This initialization process 
is controlled by routine BLU. CREATE, which creates the major 
entities played and calls, in turn, routine BASIC. LOAD to 
establish initial ammunition loads, and routine PARAMETERS 
to initialize the critical data arrays and global variables. 

1 • Generat ing Resu p ply i Re q uir ements - The B att le 
Generation of requirements to exercise the 
ammunition resupply model was initially to have been 
accomplished through interaction with the low level, high 
resolution STAR combat model. However, attempts to utilize 
the STAR battle in its current configuration led to 
difficulties with the pace of battle problem previously 
discussed in Chapter 1 and the objective was abandonned, at 
least for this thesis effort. In lieu of this, a simplified 
battle was developed strictly to generate requirements for 
the model. It must be emphasized that significant 
conclusions cannot be drawn from the battle summaries 
produced by this model. The sole function of the battle 
designed is to generate requirements in order to exercise 
the model's resupply logic. The requirements generated for 
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the model can be grouped into three broad catagories: 
ammunition expenditur es, damage and destruction of combat 
vehicles, and unit movement. The following paragraphs 
explain how the information generated is used in the model, 
a. Ammunition Expenditures 

Ammunition expenditures take place only during 
scheduled battle periods. These periods are randomly 
scheduled for six hours a day by the event BAT. L. TIME. 
Assessment of the quantities of ammunition fired by each 
weapon is determined in routine BATTLE which is called by 
each weapon system when it updates its ammunition status. In 
execution, routine BATTLE performs the following functions: 

(1) Checks if a battle is in progress - This is simply a 
check if the simulation time, TIME.V, is greater than 
the battle starting time, B.STA3T, and less than the 
battle's end time, B.END. If it is outside this limit, 
there is no active on-going battle and the routine 
returns without action. 

(2) Determines if a weapon fires - A check is made on each 
of six possible weapons carried by a weapon system to 
see if they have fired. This is accomplished by 
comparing successive random number draws against a 
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probability of firing for each ammunition owned by the 
weapon system. If the random number drawn is less 
than the assigned probability of fire, the ammunition 
being tested has fired, and expenditures are computed. 
If not, no expenditures are computed and the logic 
transfers to the next ammunition carried on the weapon 
system. 

(3) Expends Ammunition - Each of the six ammunition types 
carried by a weapon system is assigned a unique rate 
of fire. This rate of fire is stored in an array, 

ROF, which is input in routine PARAMETERS. If the 
determination is made that an ammunition has been 
fired, the quantity expended is computed through the 
use of an exponential function. Lambda for the 
function is set equal to the ammunition rate of fire 
and the exponent is completed by multiplying this 
lambda times the elapsed battle time. This technique 
inevitably causes a greater expenditure of rounds as 
the battle time increases, however, its overall effect 
on the running of the model is negligible. 
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b. Vehicle/Weapon Damage and Destruction 

Logic depicting the damage and destruction of 
vehicles and weapons was added in order to exercise the 
model's capability to adjust for ammunition assets lost 
throughout the battle. Losses and damage are generated only 
for combat weapon systems. Supply systems are not subject 
to combat loss or damage. 

The modelling of vehicle/weapon damage and 
destruction is done in routine BATTL2 with assessment of 
loss or damage limited to the 6 hour battle period. There 
are four types of damage played, M-kill, F-kill, M/F-kill, 
and K-kill. Probabilities for each type of damage are 
weapon system unique and obtained from an array, 

POD (Probability of Damage), input in routine PARAMETERS. 
Assessment of damage is accomplished by drawing a separate 
random number against each probable type of damage. If the 
number drawn is less than the probability for the type of 
damage being reviewed, the weapon sustains the damage. This 
technique leaves open the possibility that a weapon may 
sustain multiple types of damage, however, this side-effect 
is of little importance to the model's execution. 
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c. Unit Moves 

The possibility of a company relocating during 
the simulation was incorporated in order to exercise 
redistribution logic contained in the supply model. The 
assumption underlying the need for the inclusion of this 
logic is that tactical units will seek to redistribute 
ammunition either before or after displacement in order to 
achieve an ammunition balance among its weapon systems. The 
execution of a unit move within this model in no way affects 
the conduct of the remainder of the battle. Unit moves are 
scheduled randomly in event BAT. L. TIME at the start of each 
6 hour battle. Redistribution of company assets is 
accomplished upon completion of a move within each of the 
company’s platoons. Cross-leveling of ammunition between 
platoons is not modelled. In execution, each company draws 
a uniform (0,1) random number, and, if that number is less 
than a user designated probability of move, the company will 
move at the end of the battle. 

2. Dete rm ining t he Level of He ed (LON) 

The determination of Level of Need is performed 
independently and at random intervals for every weapon 
system, platoon, and company played in the simulation. The 
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purpose of an LON is tc provide an indication of the urgency 
of need an element has for each of the ammunition types it 
possesses. A distinct LON value is computed at each level 
of command. This models the increasingly wider perspective 
of the battle taken by commanders further up the chain of 
command. The net effect of this technigue is to limit the 
importance of any one ammunition type as it is factored 
against other ammunitions played. The following subsections 
fully discuss the details of the process just described, 
a. Imperfect Information 

As discussed in Section C r Chapter 3, 
information in a logistics network is approximate at best. 

In the model, this imperfection is achieved by randomizing 
the times at which ammunition updates occur at each level 
and by limiting the knowledge passed from one level to 
another to that obtained in the most recent update. The 
following example illustrates the effect of this technigue. 

A tank updates its ammunition status 10 minutes into the 
battle and finds 40 HE rounds on-board. At 30 minutes into 
the battle the tank has 30 rounds remaining. At this point, 
the platoon leader conducts an update and is informed that 
the tank has 40 rounds on-board. The platoon leader then 
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bases his decisions on this imperfection information. 

Similar update processes are performed at each level of 
command with the information provided forming the basis of 
LON computations at that level. The degree of imperfection 
in the information passed depends on the length of time 
between updates. These time intervals are entered by the 
user as input in routine PARAMETERS. 

b. Initial Assets and Capacities 

The initial ammunition assets of each weapon and 
resupply vehicle are input by the user in routine BLU. CREATE 
as the temporary attributes OH 1 through 0H6. The number of 
ammunition types that can be played in the model is 
unlimired; however, the quantity of each ammunition type on 
board a weapon system is limited to a maximum stowed load 
figure. Maximum values are set for each ammunition type and 
carried as the attributes, SL0AD1 through SL0AD6, on every 
weapon system. The stowed load configuration on a weapon 
system represents the users assessment both of what should 
be and what can be carried on a weapon system. This 
configuration is unique to each combat weapon system entity. 

The platoon and company equivalent of a stowed 
load for an ammunition type is called the base load for an 
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ammunition type. Base loads for an ammunition type are 
computed by summing over the stowed loads carried on all 
undamaged elements within a unit, 
c. Weapon LON's 

Weapon systems form the basis for all LON 
calculations in the model since i t is at the weapon level 
that ammunition is expended. Levels of need for a weapon 
system are computed in routine W.AMMO for each of the six 
possible ammunition types a weapon system might possess. 
Routine W. AMMO calls routine BATTLE to generate ammunition 
expenditures, and based on these expenditures, W.AMMO 
updates a systems knowledge of its current ammunition 
status. W.AMMO is called from several events for different 
purposes . 

Event UP. W. AMMO calls routine W. AMMO randomly 
throughout the simulation in order to model a weapon 
system's crew periodically checking its on-hand resources. 
UP. W. AMMO is scheduled individually for each weapon system 
played based on successive draws from a uniform 
distribution. The delimiting times for the distribution, 
WMIN and W MAX , are input by the user in routine PARAMETERS. 
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The event is repeatedly re-scheduled throughout the 
simulation unless the weapon updating sustains some battle 
damage. 

Events CO. RESUPPLY. ARR, REDISTRIBUTE , and 
FIR2KILL call routine W.AHMO for all undamaged weapon 
systems within a unit in order to obtain an immediate update 
of the current situation prior to executing their respective 
program segments. These calls simulate a weapon system’s 
crew checking its on-hand resources prior to any resupply 
action . 

The actual calculation of an LON for an 
ammunition type is accomplished by taking the on-hand 
ammunition of an undamaged weapon and dividing it by the 
authorized stowed load of that ammunition for that weapon. 
The resulting percentage is compared to the weapon system 
threshold values stored in the array WPNLON which is 
initially input in routine PARAMETERS. The threshold values 
contained in the array mark the lower boundaries of LON 
catagories. Figure 3 is an example of an LON calculation 
for APDS ammunition on board a tank. 
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Figure 3: Weapon LON Example 



d. Platoon LON 

Platoon LON information is updated in the 
routine P. CLASS. V. The process performed in this routine is 
essentially a summation of the information carried on-board 
the undamaged weapons in the platoon. This process updates 
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both the platoon’s current on-hand information, and the base 
load information for that ammo type. As each ammunition is 
updated, a platoon percent fill is calculated for each 
ammunition type by dividing the current on-hand quantity of 
an ammunition by its current base load in that platoon. The 
percent fill calculated is compared to the platoon LON 
threshold values for that ammunition type. These critical 
values are stored in the array PLTLON which is input in the 
routine PARAMETERS . The threshold values contained in the 
array mark the lower boundaries of the Ion categories. 

P. CLASS. V is called by several events for different 
purposes. 

Event UP. PLT. AMMO calls routine P. CLASS. V 
randomly throughout the simulation in order to model a 
platoon leader periodically checking the platoon’s on-hand 
resources. UP.PLT.AMMO is scheduled individually for each 
weapon system played based on successive draws from a 
uniform distribution. The delimiting times for the 
distribution, ? MIN and PMAX, are input by the user in 
routine PARAMETERS. The event is repeatedly re-scheduled 
throughout the simulation unless all weapons in the platoon 
sustain damage and can no longer use ammunition. 
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Events CO. RESUPPLY. ARE, REDISTRIBUTE , and 



FIREKILL call routine P. CLASS. V for all platoons within a 
unit in order to obtain an immediate update of the current 
situation prior to executing their respective program 
segments. These calls simulate a platoon leader checking 
the unit's resources prior to any resupply action. 

Figure 4 is an example of how a platoon LON is 
calculated. It is important to note in the example that the 
stowed load and on-hand ammunition of the 3rd tank is not 
considered because the tank is an M-kill. Also, the stowed 
load of tank 2 is disregarded because the weapon can no 
longer fire since it has been F-killed. The on-hand 
ammunition of tank 2 is not dropped from the computation 
however, due to the fact that the tank is still mobile and 
can be used as a resupply vehicle to deliver ammunition to 
other systems in the platoon, 
e. Company LON 

Company LON values are computed and assigned in 
routine COM.AMHO. In evaluation of this LON, the first step 
performed is to sum over all assigned platoons in order to 
update the company's on-hand and base load information. 
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Figure 4: Platoon LON Example 



A percent fill value is then computed by dividing the 
on-hand guantity for each ammunition by the required base 
load for that ammunition. This percent fill is then compared 
to company LON threshold values stored in the WPNLON array 
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which is input initially in the routine PARAMETERS. The 
threshold values contained in this array mark the lower 
boundaries of the LON values. COM. AMMO is called by several 
events for different purposes. 

Event UP. COM. AMMO calls routine COM. AMMO 
randomly throughout the simulation in order to model a 
company commander periodically checking the platoon's 
on-hand resources. UP.COM. AMMO is scheduled individually 
for each weapon system played based on successive draws from 
a uniform distribution. The delimiting times for the 
distribution, CMIN and CMAX, are input by the user in 
routine PARAMETERS. The event is repeatedly re-scheduled 
throughout the simulation unless all weapons in the company 
sustain damage and can no longer use the ammunition. 

Events CO . RESUPPLY . ARR, REDISTRIBUTE, and 
FIREKILL call routine COM. AMMO for the company receiving 
resupply in order to obtain an immediate update of the 
current situation prior to executing their respective 
program segments. These calls simulate a company commander 
checking the unit's resources prior to any resupply action. 

Figure 5 gives an example of how a company LON 
is calculated for APDS ammunition. - In this example the 
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first 



platoon data is taken from the platoon LON example 



given in Figure 4. The company example depicts 2nd platoon 
having 4 Ml tanks, each tank with a stowed load of 40 AP 
rounds and total platoon cn-hand assets of 80 AP rounds. 
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Figure 5: Company LON Example 
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In a similar manner it can be seen that the 3rd platoon has 
2 Ml tanks remaining with 20 AP rounds between them and a 
stowed load of 80 rounds, 20 per tank. 

3. Be que st s f or Res uppl y 

Resupply requests are made by a company and sent to 
the battalion's S-4 based on the information passed up the 
chain of command from the individual weapon systems through 
the subordinate platoons. Within the model logic, the 
periodic updating of ION information up zo company level is 
the key to transmission of these resupply needs. Beyond the 
company level a requisition processing system replaces the 
LON concept. Prior to the submission of a "formal" 
requisition by the company to the S-4, several informal 
actions that take place which key the submission of a 
requisition for a particular ammunition type. These actions 
occur at the weapon, platoon, and company levels. This 
section explains this informal process which results in the 
Battalion S-4 receiving a valid requisition from the 
company. 

a. Weapon Systems 

Weapon systems do not request ammunition 
resupply; they simply pass their most current knowledge to 
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the platoon at the time a platoon check is made. In the 
event that a weapon system exhausts its supply of an 
ammunition type, an immediate scheduling of the event 
DP . PLT . AMMO is made. This logic simulates a weapon system 
informing its platoon leader of the situation, and the 
platoon leader, in turn, performing a quick check of the 
rest of the platoon to see how extensive the problem is. 

b. Platoon 

Platoons do not request resupply; they 
periodically check all subordinate systems and pass on 
information for each ammunition type to the company when the 
company checks on its ammunition status. In the event that 
a platoon exhausts its supply of an ammunition type, an 
immediate scheduling of the event DP.COM. AMMO is made. This 
logic simulates a platoon leader informing the unit's 
company commander of the situation, and the company 
commander, in turn, performing a quick check of the rest of 
the company to see how extensive the problem is. 

c. Company 

The company is the first level of command 
permitted to create and submit resupply requisitions in 
order to correct deficiencies in a unit's ammunition 
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posture. Within routine CO. AMMO, changes an the Level of 
Need computed for an ammunition type trigger the creation of 
a resupply request, RES.BEQ, for that specific ammunition 
type. These requests are transmitted to battalion supply by 
scheduling the event UP. S4. AMMO and passing the company's 
requisition list as an argument to battalion. The scheduled 
time of arrival for the request is determined by drawing a 
random number from a uniform distribution. The delimiting 
times for use in the distribution, MINTRIP and MAXTRIP, are 
input in routine PARAMETERS. Use of this distribution to 
schedule the event time models the delay caused by the 
necessity to physically carry the requests to the supply 
point. 

d. Battalion 

For the purposes of this model, a battalion does 
not submit requests for resupply. Convoys returning from a 
company resupply mission are assumed to have been reloaded 
at the ASP/ATP with exactly the same quantity of ammunition 
they had just delivered to a company. In this way, 
battalion stocks are constantly refilled. 
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4 . Supply Respon s e - Action b y the S-4 

Storage and issue of a battalion's reserve 
ammunition is simulated in event UP. S4. AMMO. The purpose of 
UP. S4. AMMO is to model the actions of a battalion S-4 
officer allocating his limited ammunition and transportation 
assets in response to reguests from the supported units. 

The event is scheduled in routine COM. AMMO when a resupply 
request is created. Functionally, the routine accomplishes 
these actions through evaluation of the following 
considerations: the availability of supply and 
transportation assets; the need to maximize the use of 
shipping space on board resupply vehicles; the need to 
adjust shipments in the face of priority requests; and 
control of the dispatch of resupply convoys. The 
subsections which follow discuss each of these 
considerations. Significantly, in the program logic as it 
exists, resupply conveys are limited to one stop deliveries. 
Multiple unit deliveries are not permitted. 

a. Availability of Supply and Transportation Assets 
Stock acccuntability of ammunition is maintained 
for each CLASS 7 (ammunition) item belonging to a supply 
officer in a temporary enttiy SCL.V.ITEil. Besupply requests 



to the S-4 are matched against the on-hand balance in this 
temporary entity to determine if the supplies are available 
for release. A concurrent determination of the availability 
of transportation assets is made through a comparison of the 
total weight and cube available on resupply vehicles for 
shipping and the total weight and cube requested. 

b. Maximization of Shipping Space 

Program logic allows more than one type of 
ammunition to be loaded on a single truck. This models the 
s-4 seeking to effectively utilize the limited resources at 
his disposal. The identity of ammunition stocks released to 
fill a request is modelled through the creation of a 
temporary entity, T.CGO. This level of detail permits a 
determination of the total cargo manifest loaded on any 
individual truck. 

c. Adjustments Due to Priority Requisitions 

A key assumption modelled in the program is that 
a unit commander will order the quantity of supplies 
necessary to refill the unit's base load for an ammunition 
type. As such, in the face of multiple priority 1 and 
priority 2 requisitions and limited transportation assets, 
program logic models an S-4 decision to reduce fill on 
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individual requisitions in order to permit a greater number 
of requisitions to be filled. This reduction in fill is 
flexible subject only to the maximum lower bounds C.L1.PCT 
(CRITICAL LON 1 PERCENT) and C . L2. PCT (CRITICAL LON 2 
PERCENT) . These delimiters are input in routine PARAMETERS. 

E. RESDPPLY ACTIVITIES - RECEIPT OF SUPPLIES 

The transport of supplies to fill requisitions basically 
follows the reverse path of the requisition flow. This is to 
say that supplies are issued through xhe chain of command 
back to the weapon systems. At each level of command, new 
decisions are made as to the apportionment of the supplies 
to subordinate levels based on the most current information 
available. In executing the applicable routines modelling 
this process the first step performed is an update of the 
ammunition status of all levels. The apportionment process 
itself involves the repetitive computation at each level of 
a ratio (subordinate need / total unit need) times the 
quantity delivered. The pattern for this process is set in 
event CO. RESUPPLY. ARRIVE. This event is scheduled to mark 
the arrival of a resupply convoy at a company unit. 
Additionally, two other instances involving a similar 
reapportionment of ammunition were included in the model. 
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These are FIREKILL and REDISTRIBUTE. Event FIREKILL models 
a platoon leader's decision to distribute the ammunition 
assets from non-functional weapon systems to the remainder 
of the platoon. Event REDISTRIBUTE models an assumed 
standard operating procedure that requires platoons to 
cross-level ammunition assets between weapons after a unit 
move is executed. This routine differs from the two previous 
in that the basis for distribution of the assets is the 
ratio of the weapon system's stowed load to the platoon's 
base load times the total quantity required for the platoon. 
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APPENDIX 3 



PRO GR AM DOCUMENTATION 

This appendix provides a detailed explanation of the 
code developed for the ammunition resupply model. For this 
discussion, the model has been broken out into its major 
routines and events with each being discussed separately. 

The PREAMBLE section contains a detailed definition of every 
entity, attribute, set, and global variable used in the 
program. Thereafter, discussion of routines and events 
includes: an abbreviated glossary of terms, a listing of the 
program code, and a line by line description of the code. 

All definitions within a section are grouped by their 
SIMSCRIPT category then listed alphabetically. If an 
abbreviation is unclear an unabbreviated name is given in 
parentheses beside it. 



A. ’’PREAMBLE'* 



The preamble provides the compiler with 
regarding: entities, attributes, and sets; 
routines; global variables and arrays. Many 
descriptors used in this preamble are taken 



definitions 
events and 
of the 

directly form 
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the current STAR model. Those taken directly from STAR are 
redefined here for clarity purposes and can be identified by 
an asterisk (*) . 



1 . Routine s 

The routines of this model are described in detail 



in sections C through N of this appendix. The routines used 
are as follows: 



BLU. CREATE 
BASIC. LOAD 
P. CLASS. V 
BATTLE 

FILE. OP. DATE 
WT.AND. CUBE 



PARAMETERS 
tf .AMMO 
COM. AMMO 
UP. DATE 

LOAD. THE. TRUCKS 
PRI. RESUPPLY 



2 . Even ts 

The events for this model are explained in detail in 



sections N through Z of this appendix. The events of the 



model are: 



B. UP. DATE 
FIREKILL 
CO. RESUPPLY. AR 
UP. S4. AMMO 
STOP. SIMULATION 
UP.PLT. AMMO 



BAT. L. TIME 
BN. ARRIVE 
MOVE 

REDISTRIBUTE 
UP.COM. AMMO 
UP. W. AMMO 



3 . 



Entities 

The entities of any SIMSCRIPT program are either 
permanent., meaning they remain active throughout the 
program's execution, cr temporary, meaning they can be 
created or destroyed during program execution. Definitions 
of both type of entities are listed below. 

Pe rmane nt Ent ities 

COMPANY. COMMANDER ( rt ) . Used to model the company commander's 
thought process. Owns sets containing the unit's 
platoons (CO . UNIT composed of PLATOON .LEADERS) and the 
unit's unique ammunition listing (CO. AMMO composed of 
CCL . V. ITEMS) . 

PLATOON . LEADER (*) . Used to model the platoon leader's 

thought process. Owns sets containing the unit's weapon 
systems (PLAT. UNIT composed of TANKS) and the unit's 
ammunition listing (PLT.AMMO composed of PCL . V. ITEMS) . 
SUPPLY . OFFICER . Used tc model a battalion supply officer's 
thought process. Owns the following sets: 

S. AMMO (SUPPLY AMMUNITION). Contains the various 

ammunition types (SCL. V. ITEMS) which each supply 
officer must stock. 
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S . UNIT (SUPPLY UNIT). Contains the unit's supply 
vehicles (TANKS) . 

SWANT. LIST (SUPPLY WANT LIST). Contains the unit's 
outstanding requisitions (EES . BEQ) that must be 
filled. 

SCONVOY (SUPPLY CONVOY). Set cf ELEMENTS which make up a 
convoy. ELEMENTS, in turn, is composed cf a set of 
supply vehicles (TANKS) designated for a supply 
mission . 

T empo rary Entitie s 

CCL.V. ITEM (COMPANY CLASS V ITEM). Holds information for a 
company about a particular ammo type owned by the unit. 
Belongs to the sen C.AMMO. 

CONVOY. Holds information as to the type and amount of 

supplies being sent to a particular unit. Owns ELEMENTS 
which make up a convoy. ELEMENTS, in turn, owns the 
trucks (TANKS) that have been designated to carry the 
supplies. 

PCL.V. ITEM (PLATOON CLASS V ITEM). Holds information for a 
platoon about a particular ammo type used by the unit. 
Belongs to the set PLT.AMMO. 
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RES. REQ (RESUPPLY. REQUISITION) . Models a present day 

requisition form. Provides information between users 
and the supply system. A RES. REQ is used to hold 
requirements information for a variety of purposes 
through its membership in various sets. These are: 

C. HAST. LIST. Company information owned by a 
COMPANY. COMMANDER. 

SWANT. LIST. Supply information owned by a 
SUPPLY. OFFICER. 

C . CGO. LIST . Convoy cargo list owned by a CONVOY. 

SCL . V. ITEM (SUPPLY CLASS V ITEM). Holds information for a 
supply unit about a particular ammo type used by the 
unit. Belongs to the set S.AMMO. 

T. CGO (TRUCK CARGO). Holds information concerning the 

supplies loaded on a truck. Belongs to the set CARGO. 

TANK C* ) . Represents any vehicle or weapon system on the 

battlefield. Used to distinguish individual vehicles as 
to type and function. Tanks belong to several 
distinguishing sets: 

TNK . ALIVE (TANK ALIVE) (£) . Owned by the system this set 
keeps track of the alive/dead status of individual 
TANKS. 
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PLAT. UNIT (PLATOON UNIT). Combat systems and vehicles 
belong. Owned by a PLATOON. LEADER . 

S. UNIT (SUPPLY UNIT). Supply vehicles only belong to this 
set which is owned by a SUPPLY. OFFICER. 

M. ELEMENTS . Specifies membership in a CONVOY. 

4 . Attribu tes 

Pe rmanent At tr ibutes (I NT E GER ) 

N.CCL. V. ITEMS (NUMBER CF COMPANY CLASS V ITEMS). 

COMPANY. COMMANDER attribute specifying the number of 
ammunition types (CCL.V. ITEMS) used by the company. 
N.PCL. V. ITEMS (NUMBER OF PLATOON CLASS V ITEMS). 

PLATOON. LEADER attribute specifying the number of 
ammunition types (PCL. V. ITEMS) used by the platoon. 

N.SCL. V. ITEMS (NUMBER OF SUPPLY CLASS V ITEMS). 

SUPPLY . OFFICER attribute specifying the number of 
ammunition types (SCL . V. ITEMS) used by the battalion 
supply officer. 

PCO.CDR (PLATOON COMPANY COMMANDER). Specifies a platoon's 
commander. 

REQN (REQUISITION) . Attribute of a COMP AN Y. CO MMANDER 

specifying the total number of resupply requests filed 
by a commander. 
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SCO. CDR (SUPPLY COMPANY COMMANDER). Specifies a supply unit's 
commander . 

S4 . OFF (S 4 OFFICER). Attribute of a COMPANY. COMMANDER 
specifying the unit's supply officer. 

Tempo r ary Attr ibutes ( AL PHA) 

STATUS. Attribute of a RSS.REQ indicating where the request 
currently is. Its possible values are: T0S4 , TOCO, and 
TOATP. 

CNOMSN (COMPANY NOMENCLATURE). Attribute of a CCL.V.ITSM 
containing the nomenclature of a particular ammo. 

PNOMEN (PLATOON NOMENCLATURE) . 

RNOMEN (RESUPPLY NOMENCLATURE) . Attribute of a RES.REQ 
specifying the reguested ammo's nomenclature. 

SNOHEN (SUPPPLY NOMENCLATURE). Attribute of a SCL.V.ITEM 
specifying the requested ammo's nomenclature. 

TNOMEN (T .CGO NOMENCLATURE). Attribute of T.CGO containing 
the name of the ammunition item carried. 

Tem p orary Attr i bute s [INTEGER h 

AMM01 (*) (AMMUNITION 1). This variable is used as a shortened 
form for AP.TOW ammunition. 

AMH02(*) (AMMUNITION 2). This variable is used as a shortened 
form for HE. DRAG ammunition. 
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AH MO 3 (***) (AMMUNITION 3). This variable is used as a shortened 
form for AW1.0R.MSL3 ammo. 

AMM04 (*) (AMMUNITION 4). This variable is used as a shortened 
form for AW2.0R.ADM ammo. 

AMM05 (* ) (AMMUNITION 5). Actual on-hand balance of the fifth 
ammo type fired by a TANK. 

AMM06 ) (AMMUNITION 6). Actual on-hand balance of the sixth 
ammo type fired by a TANK. 

AP.TOW (£) (ARMOR PIERCING/TOW) Actual on-hand balance of the 
first ammo type fired by a TANK. 

TAC (TANK AMMUNITION CODE). Supply code which points to a 
specific ammunition fired by a TANK. Six are specified 
on a TANK: 

TAC1 (TANK AMMUNITION CODE 1). Contains the code value 
for the first ammo type fired by a TANK. 

TAC2 (TANK AMMUNITION CODE 2). Contains the code value 
for the second ammo type fired by a TANK. 

TAC3 (TANK AMMUNITION CODS 3). Contains the code value 
for the third ammo fired by a TANK. 

TAC4 (TANK AMMUNITION CODE 4). Contains the code value 
for the fourth ammo fired by a TANK. 
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TAC5 (TANK ATI MUNITION CODE 5). Contains the code value 
for the fifth ammo fired by a TANK. 

TAC6 (TANK AMMUNITION CODE 6) . Contains the code value 
for the sixth ammo fired by a TANK. 

AW1 .OR. MSL3 (*) (ALTER WEAPON1 OR MISSILE3 AMMUNITION). Actual 
on-hand balance for the third ammo fired by a TANK. 

AW2 . OR . ADM (*) (ALTER WEAPON2 OR AIR DEF MISSILE). Actual 
on-hand balance for the fourth ammo fired by a TANK. 

C.CMBT. LOSS (COMPANY COMBAT LOSS). Attribute of a CCL.V.ITEM 
indicating whether the need for an ammo type is still 
viable. 

C.MV. STATE (CONVOY MOVEMENT STATE). Indicates if a convoy has 
left its start point. Eguals *'0" at the start point and 
"1" if departed. 

C.NUM. REQ (COMPANY NUMBER OF REQUESTS). Attribute of a 

CCL.V.ITEM containing the total number of requests made 
for that ammo type. 

C.RND.CNTR (COMPANY ROUND COU NTER) . Argument for the event 

UP . COM. AMMO , points to the weapon system it is updating. 

C. SHORT (COMPANY SHORTAGE). Attribute of a CCL.V.ITEM holding 
the number of rounds the company is short for that round 
type. 



123 



CAC (COMPANY AMMUNITION CODE). Attribute of a CCL.V.ITSM 
which points to a specific ammo type fired by the 
company weapon systems. 

CAMMO. LON (COMPANY AMMUNITION LEVEL OP NEED). Attribute of a 
CCL.V.ITSM indexing the company's overall need for an 
ammo type. 

CCURR. LOAD (COMPANY CURRENT LOAD). Attribute of a CCL.V.ITEM 
holding the company commander's knowledge of the on-hand 
balance for rounds of a particular type. 

CO. B. LOAD (COMPANY BASE LOAD). Attribute of a CCL.V.ITEM 

holding the total number of rounds the company needs to 
be at optimal fill. 

CO. CNVY (COMPANY CONVOY). Argument Of event CO. RESUPPLY. ARR 
(COMPANY RESUPPLY ARRIVE) pointing tc the CONVOY 
arriving. 

COCDR (COMPANY COMMANDER). Attribute of a TANK pointing to 
its COMPANY .COMMANDER. 

COLOR (*). Attribute of TANK indicating the TANK'S force 
membership. 

"0" indicates RED FORCE 
”1" indicates BLUE FORCE 

CONTRKS (CONVOY TRUCKS). Attribute of a CONVOY specifying the 
number of vehicles in a particular convoy. 
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CPNTR (CONVOY POINTER). Attribute of a T.CGO pointing to the 
convoy the cargo is leaded on. 

CRESUPPLY. REQ (COMPANY RESUPPLY REQUEST). Attribute of a 
CCL.V. ITEM indicating whether a RES. REQ has been 
submitted previously. 

CU. PK3 (CU3 E PACKAGE). Attribute of a SCL.V.ITEM specifying 
the cube of an ammunition pallet. 

DEMAND. Attribute of a SCL.V.ITEM holding the total demand 
for an ammo type. 

DISTR (DISTRIBUTOR) . Argument for event REDISTRIBUTE pointing 
to the unit’s PLATOON . LEADER 

FKILL (FIREPOWER KILL) (*) . Indicates whether a TANK has 

sustained a firepower kill during the battle. 

"0” indicates no 
”1” indicates yes 

MARCH. ORDER. Argument for the event MOVE holding the pointer 
of the company receiving orders to move. 

HE. DRAG (HIGH EXPLOSIVE/DRAGON AMMUNITION) (*) . Actual on-hand 
balance of the second ammo type fired by a TANK. 

ISSUER. Argument of event UP. S4. AMMO pointing to the S-4 
currently updating. 

ISSUEE. Argument of event UP. S4. AMMO pointing to the company 
initiating the reguest for resupply. 
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KKILL (CATASTROPHIC KILL) (*). Indicates whether a TANK has 

sustained a catastrophic kill during the battle. 

"0" indicates no 
"1" indicates yes 

MANIFEST. Attribute of a RES.REQ pointing to the CONVOY 
supplies are loaded on. 

MAX. CUBE. Attribute of a TANK indicating its max cargo cube. 

MAX . WT . Attribute of a TANK indicating its max cargo weight. 

MFKILL (M03ILITY/FIREP0HER KILL) (*) . Indicates whether a TANK 

has sustained mobility and firepower damage. 

”0” indicates no 
"1" indicates yes 

MKILL (MOBILITY KILL) (#) . Indicates whether a TANK has 

sustained mobility damage. 

"0" indicates no 
"I" indicates yes 

N . T . ALLOC (NUMBER OF TRUCKS ALLOCATED). Attribute of a 

! 

RES.REQ indicating the total number of trucks allocated 
to move a RES.REQ. 

NAME (* ) . Indicates the number of a TANK in the battle. 

ONHAND. Attribute of a SCL.V.ITEM holding the balance 
on-hand of stocks for an ammo type. 

0H1 (ON-HAND 1). Current balance of ammunition 1 on a TANK. 

0H2 (ON-HAND 2). Current balance of ammunition 2 on a TANK. 

0H3 (ON-HAND 3). Current balance of ammunition 3 on a TANK. 
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0H4 (ON-HAND 4). Current balance of ammunition 4 or. a TANK. 

0H5 (ON-HAND 5). Current balance of ammunition 5 on a TANK. 

0H6 (ON-HAND 6). Current balance of ammunition 6 on a TANK. 

P . CMBT .LOSS(PLATOON COMBAT LOSS). Attribute of a PCL.V.ITEM 
indicating whether the need for an ammo type is still 
viable . 

P.RND. CNTR (PLATOON ROUND COUNTER). Argument of event 

UP . PLT . AMMO pointing to the platoon currently updating. 

P. SHORT (PLATOON SHORTAGE). Attribute of a PCL.V.ITEM holding 
the quantity of that ammo the platoon is currently 
short. 

PAC (PL ATOO N AMMUNITION CODE). Attribute of a PCL.V.ITEM 
which points to a specific ammo type fired by the 
platoon. 

PAMMO. LON (PLATOON AMMUNITION LEVEL Of NEED). Attribute of a 
PCL.V.ITEM indexing the platoon's overall need for an 
ammo type. 

PCURR. LOAD (PLATOON CURRENT LOAD). Attribute of a PCL.V.ITEM 
holding the platoon leader's knowledge of the on-hand 
balance for rounds of a particular type. 

PNOMEN (PLATOON NOMENCLATURE). Attribute of a PCL.V.ITEM 
containing the nomemclature of a particular ammo. 
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PL. B . LOAD ( PLATOON BASE LOAD). Attribute of a PCL.V.ITEM 

holding the total number of rounds the platoon needs to 
be at optimal fill for that type ammunition. 

PLTLDR (PLATOON LEADER) (*) . Attribute of a TANK. 

POINTER (***) . Contains the machine address of a particular 
TANK. 

RAC (RESUPPLY AMMUNITION CODS). Attribute of an SCL. V. ITEM 
which points to a specific ammo type carried by the 
supply unit. 

RCNVY (RESUPPLY CONVOY). Argument of event BN. ARRIVE pointing 
to a specific convoy. 

RDS.PKG (ROUNDS PACKAGE). Attribute of a SCL. V. ITEM 

specifying the number cf rounds on an ammo pallet. 

REQUESTOR. Attribute of a RES. REQ pointing to the requesting 
unit. 

RFILL (RESUPPLY FILL). Attribute of a RES. REQ specifying the 
amount of ammunition released to fill a request. 

RND.CNTR (ROUND COUNTER). Argument of event UP. W. AMMO 
pointing to the TANK currently updating. 

RP (RELEASE POINT). Attribute of a CONVOY specifying its 
destination . 
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RPNTR (REQUEST POINTER). Attribute of a RES.REQ containing 
its pointer value. 

RRPNTR (RES.REQ POINTER). Attribute of T.CGO which points to 
the RES.REQ the supplies are meant to fill. 

RQTY (RESUPPLY QUANTITY). Attribute of a RES.REQ holding the 
total quantity requested by a unit. 

RAC (RESUPPLY AMMUNITION CODE). Attribute of a RES.REQ which 
points to a specific ammo being requested. 

SAC (SUPPLY AMMUNITION CODE). Attribute of a SCL.V.ITEM 

pointing to the particular ammo carried by the supply 
unit . 

SCREEN. Attribute of a RES.REQ indicating whether a RES.REQ 
has been looked at during an S-4 update. 

SL0AD1 (STOWED LOAD 1) . Attribute of a TANK specfying the 
optimal load for ammo type 1. 

SL0AD2 (STOWED LOAD 2) . Attribute of a TANK specfying the 
optimal load for ammo type 2. 

SL0AD3 (STOWED LOAD 3) . Attribute of a TANK specfying the 
optimal load for ammo type 3. 

SL0AD4 (STOWED LOAD 4). Attribute of a TANK specfying the 
optimal load for ammo type 4. 
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SL0AD5 {STO WED LOAD 5) . Attribute of a TANK specfying rhe 



optimal load for ammo type 5. 

SL0AD6 (STOWED LOAD 6) . Attribute of a TANK specfying the 
optimal load for ammo type 6. 

SP (START POINT) . Attribute of a CONVOY specifying its 
origin. 

SPACE. Attribute of a CONVOY holding the amount of loading 
space available on trucks in the convoy. 

SPKIORITY (SUPPLY PRIORITY). Attribute of a RES. REQ 

specifying the urgency of need for the ammo request. 

SUPOFF (SUPPLY OFFICER) (*) . Attribute of a resupply vehicle. 

SYS. TYPE (SYSTEM TYPE) {*>) . Attribute of a TANK specifying the 
general system type of the entity. 

1 TANK 

2 Mounted Infantry 

3 Dismounted Infantry 

4 Artillery 

5 Air 

6 Air Defense 

7 Suoply 

8 Comm/EW/Acg/Intel 

9 Other 

TCU (TRUCK CUBE) . Attribute of a TANK holding the maximum 
cube loaded on a truck. 

TPNTR (TRUCK POINTER). Attribute of a T.CGO pointing to the 
truck it is loaded on. 

TQTY (T . CGO QUANTITY). Attribute of a T.CGO containing the 
quantity loaded as cargo. 
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TRAC (T . CGO 3ES0PPLY A MKO CODE). Attribute of T.CGO pointing 



to the ammo type loaded as cargo. 

TWT (TRUCK WEIGHT). Attribute of a TANK holding the maximum 
weight if can carry. 

TIME. Attribute of a RSS.REQ containing the time a request 
is initiated at the company. 



WL0N1 (WEAPON 
AMMO 1 . 


LEVEL OF NEED 1). Weapon system urgency of need 


WL0N2 (WEAPON 
AMM02. 


LEVEL OF NEED 2) . Weapon system urgency of need 


WLON3 (WEAPON 
AMMO 3. 


LEVEL OF NEED 3). Weapon system urgency of need 


WL0N4 (WEAPON 
AMM04. 


LEVEL OF NEED 4). Weapon system urgency of need 


WLON5 (WEAPON 
AM MO 5. 


LEVEL OF NEED 5) . Weapon system urgency of need 


WL0N6 (WEAPON 
AMM06. 


LEVEL OF NEED 6) . Weapon system urgency of need 



WPN. TYPE (WEAPON TYPE) (*) . Attribute of a TANK specifying the 
specific weapon system within a SYS . TYPE (SYSTEM TYPE). 
WT.PKG (WEIGHT PACKAGE). Attribute of a SCL.V.ITEM specifying 
the weight of a pallet of the ammo being considered. 
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5 • Sets 

The sets used in the model are listed and defined as 

follows : 

C.CGO. LIST (CONVOY CARGO LIST). Owned by a CONVOY. Members 
are RES.REQs. 

CO. AMMO (COMPANY AMMUNITION). Owned by a COMPANY. COMMANDER. 

Members are the unit's CCL.V. ITEMS. 

CO. UNIT (COMPANY UNIT). Owned by a COMPAN Y. COMMANDER. Members 
are unit PLATOON. LEADERS. 

CARGO (TRUCK CARGO). Owned by a supply vehicle. Members are 
the supplies (T. CGO) loaded. 

CWANT. LIST (COMPANY WANT LIST). Owned by a COMPANY. COMMANDER. 

Attributes are the unit's outstanding resupply requests. 
ELEMENTS. Owned by a convoy. Members are TANKs in the 
convoy . 

PLAT. UNIT (PLATOON UNIT). Owned by a PLAYOON. LEADER. Members 
are unit combat vehicles. 

PLT. AMMO (PLATOON AMMUNITION). Owned by a PLATOON . LEADER. 

Members are the platoon PCL.V. ITEMS. 

S. AMMO (SUPPLY AMMUNITION). Owned by a SUPPLY . OFFICER . 

Members are the supply unit's SCL.V. ITEMS. 
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S. UNIT (SUPPLY UNIT). Owned by a SUPPLY .OFFICER . Members are 
unit supply trucks. 

SCONVOY (SUPPLY CONVOY). Owned by a SUPPL Y. OFFICER . Members 
are convoys dispatched by the supply unit. 

SREQN. LIST (SUPPLY REQUISITION LIST). Owned by a 

SUPPLY . OFFICER. Members are the supply unit's 
outstanding RES . REQs sent to the ATP . 

SUP. OFF (SUPPLY OFFICER). Attribute of TANK pointing to its 
supply officer. 

SWANT. LIST (SUPPLY WANT LIST). Owned by a SUPPLY. OFFICER. 

Members are RES. REQs from the combat units. 

TNK. ALIVE (TANK ALIVE) (*) . Owned by the system. Members are 
vehicles still alive within the simulation. 

6 . Global Variab l es 

The global variables used in the model are either 
alpha, integer or real. An explanation of their use is as 
follows : 

Glob al V ariables (ALPHA) 

NOMEN (NOMENCLATURE) . Specifies the names of the rounds 
played . 

Global Variables (INTEGER) 
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CCODB (COMPANY CODE). Holds the pointer value for a company's 
CCL. V. ITEMS 

CNU M (COMPA NY NUMBER) (*) . Specifies the number of 
COMPANY. COMMANDERS created. 

CSTREAM (COMPANY STREAM) . Specifies the random number stream 
used for company calculations. 

N. SYS (NUMBER 0? SYSTEMS). Specifies the number of weapon 
systems created for the simulation. 

N. TANKS (NUMBER OF TANKS) . Specifies the number of vehicles 
created for the simulation. 

N. WPN. TYPES (NUMBER OF WEAPON TYPES). Specifies the number of 
weapons created for the simulation. 

PCODE (PLATOON CODE) (2-d) . Holds the pointer value for a 
platoon's PCL.V. ITEMS. 

PNUM (PLATOON NUMBER) (*) . Specifies the number of 
PLATOON. LEADERS created for a simulation. 

PSTRE AM (PLATOON STREAM). Specifies the random number stream 
to be used for platoon calculations. 

RCODE (REQUEST CODE) (2-d). Holds the pointer value for 
resupply requests created. 

RSTREAM (RESUPPLY STREAM). Specifies the random number stream 
to be used for resupply calculations . 
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SCODE (SUPPLY CODE) ( 2— d) . Holds the pointer value for a 
supply unit's SCL . V. ITEMS. 

SNUM (SUPPLY NUMBER). Specifies the number of SUPPLY. OFFICERS 
created for a simulation. 

TSTREAI1 (TRIP STREAM) . Specifies the random number stream to 
be used for movement calculations. 

MSTREAM (WEAPON STREAM). Specifies the random number stream 
to be used for weapon update calcula tions . 

Glob al Var ia bles ( REAL )_ 

B. END (BATTLE END). Holds the termination time for a day's 
battle . 

B. START (BATTLE START) . Holds the beginning time for a day's 

battle . 

C. L1PCT (CRITICAL L0N1 PERCENTAGE). Holds the maximum 

percentage that LON1 requisitions may be reduced no in 
order to release space on a convoy for other critical 
L0N1 and LON2 requests. 

C.L2CU (CRITICAL LON2 CUBE). Holds the maximum percent of 
cube that L0N2 requisitions may be cut to in order to 
release space on a convoy for other critical LON 1 and 
L0N2 requisitions. 
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C.L2WT (CRITICAL L0M2 WEIGHT) . Holds the maximum percent of 
weight that L0N2 requisitions may be cut to in order to 
release space on a convoy for other critical L0N1 and 
L0N2 requisitions. 

CMAX (COMPANY MAXIMUM) . The maximum rime that can elapse 
before a company will update its ammunition status. 

CMIN (COMPANY MINIMUM) . The minimum time that can elapse 
before a company will update its ammunition status. 

COMLON (COMPANY LEVEL OF NEED) ( 2-d) . Array holding the value 
of a COMPANY. COMMANDER' s cutoff percentages for the five 
levels of need which can be assigned. Dimensioned as 
MAX. CL. V. ITEMS (MAX CLASS V ITEMS) by 5. 

MAXTRIP (MAX TRIP). The maximum time required for a convoy to 
reach its intended destination. 

M INTRIP (MIN TRIP). The minimum time required for a convoy to 
reach its intended destination. 

PLTLON (PLATOON LEVEL OF NEED) (2-d) . Array holding the value 
of a PLATOON. LEADERS ' s cutoff percentages for the five 
levels of need which can be assigned. Dimensioned as 
MAX. CL. V. ITEMS (MAX CLASS V ITEMS) by 5. 

PMAX (PLATOON MAXIMUM). The maximum time that can pass before 
a platoon will update its ammunition status. 
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PMIN (PLATOON MINIMUM) . The minimum time that can pass before 
a platoon will update its ammunition status. 

POD (PROBABILITY OF DAMAGE) (2-d). Array holding the 

probability of damage for the various weapon types and 
types of damage. Dimensioned N . WPN . TYPES (NUMBER OF 
WEAPON TYPES) by 4. 

POF (PROBABILITY OF FIRE) (2-d) . Array holding the probability 
of firing for the various weapon types and ammunitions 
fired. Dimensioned N. WPN. TYPES (NUMBER OF WEAPON TYPES) 
by 4 . 

ROF (RATE OF FIRE) (2-d) . Specifies the rates of fire for the 
six weapons of any weapon system. Dimensioned 
N. WPN. TYPES (NUMBER OF WEAPON TYPES) by 6. 

WMAX (WEAPON MAXIMUM). The maximum time that can pass before 
a weapon will update its ammunition status. 

WMIN (WEAPON MINIMUM). The minimum time that can pass before 
a weapon will update its ammunition status. 

WPNLON (WEAPON LEVEL OF NEED) (2-d). Array holding the value 
of a weapon system's cutoff percentages for the five 
levels of need which can be assigned. Dimensioned as 
MAX. CL. V. ITEMS (MAX CLASS V ITEMS) by 5. 
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List ing 



1 PREAMELE 

DEFINE WPNLON ,PLTLON, A ND COilLON AS R2AL,2-Di:i ARRAYS 
DEFINE ROF AS INTEGER, 2-DIM ARRAY 
DEFINE NOMEN AS AN ALPHA, 1-DIM ARRAY 
DEFINE PLACES AS A 2-DIM INTEGER ARRAY 

i i 

DEFINE POD AS REAL, 2-DIM ARRAY 
GENERATE LIST ROUTINES 

t i 

THE SYSTEM OWNS SOME TNK. ALIVE 

t t 
i • 

PERMANENT ENTITIES 

i i 

EVERY COMPANY. COMMANDER HAS AN N .CCL . V . I TEMS , 

AN S4 . OFF , A REQN , 

OWNS A CO. UNIT, A CW ANT . LIST , AND SOME CO. AMMO 
DEFINE N. CCL. V. ITEMS, S4. OFF, REQN AS INTEGER 
VARIABLES 

« • 

EVERY PLATOON. LEADER HAS A ?CO.CDR,AN N . PCL . V . ITE MS , 
MAY 3EL0NG TO A CO. UNIT, 

AND MAY OWN A PL AT . UNIT , AND A PLT.AMMO 

DEFINE PCO.CDR, N . PCL. V . ITEMS AS INTEGER VARIABLES 

• i 

EVERY SUPPLY. OFFICER HAS A SCO.CDR,A N. SCL. V . ITEMS , 
OWNS SOME 5. AMMO, AN S. UNIT, AN SWANT.LIST, 

AN SREQN.LIST, AND AN SCONVOY 

DEFINE SCO . CD R , N . SC L. V . ITEMS AS INTEGER VARIABLES 

« t 

• « 

TEMPORARY ENTITIES 

« « 

EVERY TANK HAS A NAME, A COLOR, A SYS. TYPE, A WPN.TYPE, 
A POINTER, AN AP.TOW,AN HE. DRAG, AN AW1.0R.MSL3, 

AN AW2 . OR. ADM , AN AMM05 , AN AMM06 , 

A SLO AD 1 , A SLOAD2, A SLOAD3 , A SLOAD4,A SLOAD5 , 

A SLO AD 6 , AN OH1,AN OH2.AN OH3,AN 0H4.AN Oa5,AN OH6, 

A WLON 1 , A WLO N2, A WLON3,A WLON4,A WL0N5,A WLON6, 

AN TAC1 , AN TAC2, AN T AC 3 , AN T AC4 , AN TAC5 , AN TAC6 , 

A PLTLDR ,A COCDR,A SUPOFF,A MAX. WT,A MAX. CUBE, 

A TW' T ',A TCU 

AN MKlLL , AN FKILL , AN MFKILL, A KKILL, 

AND MAY BELONG TO A TNK. ALIVE, A PLAT. UNIT, A S.UNIT, 

AND A ELEMENTS, AND MAY OWN SOME CARGO 

• « 

DEFINE N. TANKS AS AN INTEGER VARIABLE 
DEFINE NAME, COLOR. SYS. TYPE, WPN. TYPE, SUP. OFF, POINTER, 
A?. TOW, HE. DRAG, AW1 .OR. MSL3,AW2.0R. ADM. AMM05 , AMM06 , 
SLOAD1 , SLOAD2,SLOAD3,SLOAD4,SLOAD5, 5LOAD6, 
OH1,OH2,OH3,OH4,OH5,OH6 , 

WLON1 ,WLON2,WLON3, WLON 4, WLON 5, WLON6, 

TAC1 ,TAC2,TAC3.TAC4,TAC5.TAC6 , 

PLTLDR, COCDR,SUPOFF, MAX. WI , MAX. CUBE, 

TWT, TCU 

MKILL, FKILL, MFKILL, AND KKILL AS INTEGER VARIABLES 

EVERY T.CGO HAS A TPNTR , A RRPNTR , A TRAC, A 'T NOMEN , 

A TQTY , AND MAY BELONG TO A CARGO 

DEFINE TPNTR, RRPNTR, TRAC, TQTY AS INTEGER VARIABLES 
DEFINE TNOMEN AS AN ALPHA VARIABLE 

i « 

EVERY CONVOY HAS AN SP,AN RP.A CONTRKS, A SPACE, 

A C. MV. STATE, A CPNTR ,M AY BELONG TO A SCONVOY, MAY OWN 
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SOME ELEMENTS, AND A C.CGO.LIST 

DEFINE CPNTR,SP,RP, SPACE, C. MV. STATE, AND CONTRKS AS 
INTEGER VARIABLES 

t i 

EVERY PCL. V .ITEM HAS A PAC,A PNOMEN.A PL. B. LOAD, 

A PCURR. LOAD, A PAM MO . LON , A P . CM B T. LO SS, A P. SHORT, AND 

MAY BELONG TO A PLT.AMMO 

DEFINE P AC, PL. B. LOAD, PCURR. LOAD, 

PAMMO. LON, P. SHORT, P.CM3T. LOSS AS INTEGER VARIA3LES 
DEFINE PNOMEN AS AN ALPHA VARIABLE 

i « 

EVERY CCL . V . ITEM HAS A CAC,A CNOMEN , A CO. B. LOAD, 

A CCU HR. LOAD, A C . NUM . REON, A CAMMO.LON.A C. SHORT, 

A C.CMBT. LOSS, AND MAY BELONG TO A CO. AMMO 

DEFINE CAC , CO . B. LO AD , CCURR . LOAD , C. NUM.REQN,C . SHORT, 

C.CMBT. LOSS, CAMMO. LON AS INTEGER VARIABLES 

DEFINE CNOMEN AS AN ALPHA V ARIA3LE 

• » 

EVERY SCL. V . ITEM HAS AN SAC, AN S NOMEN, A WT.PKG, 

A CU . ?KG , A RDS.PKG , A DEMAND, AN ONHAND, AND 
BELONGS TO AN S. AMMO 

DEFINE SAC, RDS.PKG, DEMAND, ONHAND AS 
INTEGER VARIABLES 

DEFINE 5 NO MEN AS AN ALPHA VARIABLE 
DEFINE WT.PKG, AND CU.PKG AS REAL VARIABLES 

• t 

EVERY RES.REQ HAS A REQUESTOR, A RQTY , A RAC, 

AN RNO MEN, AN SPRIORITY.A STATUS, A TIME, AN RFILL, 

AN N . T . ALLOC , A MANIFEST, A SCREEN, AN RPNT R, AN D MAY 
BELONG TO A C.CGO.LIST, A CWANT.LIST, 

AN SREQN. LIST, AND AN SWANT.LIST 

DEFINE REQUESTOR. RQTY, RAC, S PRIORITY, MANIFEST , 

RPNTR, SCREEN, RFILL, N.T. ALt0C AS INTEGER VARIABLES 
DEFINE TIME AS A REAL VARIABLE 
DEFINE STATUS AS AN ALPHA VARIABLE 
DEFINE RNOMEN AS A ALPHA VARIABLE 

i • 
i t 

" GENERAL DEFINITIONS 

i t 

DEFINE PNUM.CNUM.SNUM, tf STREA M, PS TREA M ,CS TREAM , 
TSTREAM,RSTREAM,N. SYS, AND N . WPN . TYPES 
AS INTEGER VARIABLES 

DEFINE WMIN,WMAX,PMIN,PMAX,CMIN, CM AX , 

MINTRIP , AND MAXTRIP AS REAL VARIABLES 
DEFINE B. START, AND B.END AS REAL VARIABLES 
DEFINE SWANT.LIST AS A SET RANKED BY LOW SPRIORITY, 
THEN BY LOW TIME 

DEFINE PCODE AS AN INTEGER, 2-DIM ARRAY 
DEFINE CCODE AS AN INTEGER , 2-DIM ARRAY 
DEFINE SCODE AS AN INTEGER, 2-DIM ARRAY 
DEFINE RCODS AS AN INT EGER , 2-DIM ARRAY 
DEFINE AMM0 1 TO MEAN AP.TOW 
DEFINE AMM02 TO MEAN HE. DRAG 
DEFINE AMM03 TO MEAN AW1.OR.MSL3 
DEFINE AMM04 TO MEAN AW2.OR.ADM 
DEFINE C.L2WT,C.L2CU,C.L2PCT,C.L1 PCT 
AS REAL VARIABLES 

i t 
t » 

• • EVENT NOTICES 

< i 

EVENT NOTICES INCLUDE STOP . SIMULATION , B. UP. D ATE, 

AND BAT. L. TIME 

EVERY UP. W. AMMO HAS A RND.CNTR 

EVERY UP. PLT.AMMO HAS A P. RND.CNTR 

EVERY UP.COM. AMMO HAS A C. RND.CNTR 

EVERY UP. S4. AMMO HAS A ISSUER, AND AN ISSUES 
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134 EVERY MOVE HAS A MARCH. ORDER 

135 EVERY CO. RESUPPLY. ARR HAS A CO.CNVY 

136 EVERY BN. ARRIVE HAS AN RCNVY 

137 EVERY REDISTRIBUTE HAS A DISTR 

138 EVERY FIREKILL HAS A VICTIM 

139 DEFINE VICTIM , RND. CNTR, P .RND. CNTR, C. R ND. CNTR , ISSUER, 

140 ISSUEE. CO.CNVY, MARCH. ORDER, RCNVY, AND DISTR 

141 AS INTEGER VARIABLES 



B. "MAIN" 



The purpose of the main program is to call routines than 



create blue forces, to schedule the events that generate 



data, and to start/stop the simulation. 



EV ENT N OTICE S 



B. UP. DATE (BATTLE UPDATE), BAT. L. TIME (BATTLE TIME), 



STOP. SIMULATION 



RECURSIVE VARIABLES (REAL) 



SIM. STOP Holds the time for simulation termination. 



ROUTINES CALL ED 



BLU. CREATE 



PR OGRA M LISTI NG 



1 MAIN 

2 ' ’ 

3 DEFINE SIM. STOP AS A REAL VARIABLE 

4 READ SIM. STOP 

5 SCHEDULE A STOP. SIMULATION IN SIM. STOP DAYS 

6 SKIP 2 CARDS 

7 CALL BLU. CREATE 

3 SCHEDULE A BAT. L. TIME NOW 
9 SCHEDULE A B. UP. DATE NOW 

10 PRINT 1 LINE THUS 

START SIMULATION 

11 START SIMULATION 

12 STOP 

13 END 

EX PLA NATI ON O F CODE 



Line 3 Defines recursive variables used in the routine. 
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Line 4 



Reads simulation stop time 



Line 5 Schedules the event STOP. SIMULATION. 

Line 7 Calls routine BLU. CREATE. 

Line 8 Schedules the first 3AT. L. TIME event. 

Line 9 Schedules printing of the first battle summary. 

Line 10 Prints a statement to mark simulation start. 

Line 1 1 System command to start the simulation. 

C. "ROUTINE BLU. CHEATS" 

Routine BLU. CREATE is called from the main program to 
create the entities of each blue unit. After creating these 
entities, it establishes their attributes and files each 
entity in its appropriate set. 

EVENTS SCH EDULED 
UP. W . AMMO ( UPDAT E WEAPON AMMO). 

GL OBAL VARIABL ES (INTEGER) 

CNU M (COMPANY NUMBER). Specifies the number of 
COMPANY. COMMANDERS created. 

CSTREAM (COMPANY RANDOM NUMBER STREAM). 

N. COMPANY. COMMANDERS (NUMBER OF COMPANY COMMANDERS). 

N. PLATOON. LEADERS (NUMBER OF PLATOON LEADERS). 

N. SUPPLY. OFFICERS (NUMBER OF SUPPLY OFFICERS). 

N. TANKS (NUMBER OF TANKS). 

PNUM (NUMBER OF PLATOONS). 
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PSTREAM (PLATOON RANDOM NUMBER STREAM). 



SNUM (NUMBER OF SUPPLT OFFICERS) . 

GL03AL_VARIABLES_iREALl 

CMAX (COMPANY MAXIMUM). The maximum time that can pass before 
a company will update its ammunition status. 

CMIN (COMPANY MINIMUM) . The minimum time that can pass before 
a company will update its ammunition status. 

PMAX (PLATOON MAXIMUM). The maximum time that can pass before 
a platoon will update its ammunition status. 

PMIN (PLATOON MINIMUM) . The minimum time that can pass before 
a platoon will update its ammunition status. 

WMAX (WEAPON MAXIMUM). The maximum time that can pass before 
a weapon will update its ammunition status. 

WMIN (WEAPON MINIMUM). The minimum time that can pass before 
a weapon will update izs ammunition status. 

PERMANEN T ENT ITIES 

COMPANY. COMMANDER, PL ATOON . LEADER, SUPPLY. OFFICER 



PERMANE NT A TTRIBUTES (INTEGER) 

N.CCL. V. ITEMS. Number of company class V items (unique to a 
company commander) . 

N.PCL.V. ITEMS. Number of platoon class V items (UNIQUE TO A 
PLATOON LEADER) . 
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N. SCL. V. ITEMS . Number of supply class V items (UNIQUE TO A 
SUPPLY OFFICER) . 

PCO.CDR. (PLATOON COMPANY COMMANDER) . 

SCO.CDR. (SUPPLY COMPANY COMMANDER) . 

S4.0FF. (COMPANY S-4 OFFICER) . 

RECURSIV E V ARIABLES (I NTEGER) 

I - Loop index. 

RO UTIN E S CALL ED 

BASIC . LOAD , PARAMETERS 

SETS 

CO. UNIT (COMPANY UNIT). Owned by a COMPANY. COMMAN DER. 

Members are the unit's PLATOON . LEADERS . 

PLAT. UNIT (PLATOON UNIT). Owned by a PLATOON. LEADER. Members 
are the unit's combat vehicles (TANKS) . 

S. UNIT (SUPPLY UNIT). Owned by a SUPPLY .OFFICER. Members are 
the unir's supply vehicles (TANKS) . 

TNK.ALIVE(TANK ALIVE) . Owned by the system. Members are 
vehicles still alive within the simulation. 

TEMPORA RY E NTITIES 

TANK. A temporary entity used to represent all vehicles on 
the battlefield. Its attributes distinguish the 
individual vehicles as to type and function. 

TEMP ORARY ATTRIBUTES (I NTE GER) 



143 



AMM05 (AMMUNITION 5) . 

AilM06 (AMMUNITION 6). 

AP.TOW (ARMOR-PIERCING/TOW) . Ammunition 1. 

TAC 1 . (TANK AMMUNITION CODE 1). 

TAC2. (TANK AMMUNITION CODE 2). 

TAC3. (TANK AMMUNITION CODE 3). 

TAC4 . ( TANK AMMUNITION CODE 4). 

TAC5. (TANK AMMUNITION CODE 5) . 

TAC6. (TANK AMMUNITION CODS 6). 

AW1.0R.MSL3(ALTERNATE WEAPON 1 OB MISSILE 3) . Ammunition 3. 
AW2. OH. ADM (ALTERNATE WEAPON 2 OR AIR DEEENSE MISSILE). 
Ammunition 4. 

COCDR (COMPANY COMMANDER). Of a TANK. 

COLOR This attribute of a TANK indicates the TANK'S force 
membership. "0" indicates RED FORCE, "1" indicates 3LUE. 
HE. DRAG (HEAT/DRAGON ROUNDS). Ammunition 2. 

MAX. CUBE. Indicates the max cargo cube a resupply 
vehicle (TANK) is designed to move. 

MAX.WT. Indicates the max cargo weight a resupply 
vehicle (TAN K) is designed to move. 

NAME. Indicates the number of a TANK in the battle. 

PLTLDR (PLATOON LEADER). Of TANK. 

POINTER. Combat vehicle's machine address. 
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RND.CNTR (ROUND COUNTER). Argument of routine W. AMMO ( WEAPON 
AMMUNITION) carrying the value of the TANK updating. 



SLOAD1 (STOWED LOAD 1) . Optimal load ammo type 1. 

SLOAD2 (STOWED LOAD 2) . Optimal load ammo type 2. 

SLOAD3 (STOWED LOAD 3) . Optimal load ammo type 3. 

SLOAD4 (STO WED LOAD 4) . Optimal load ammo type 4. 

SL0AD5 (STOWED LOAD 5) . Optimal load ammo type 5. 

SLOAD6 (STOWED LOAD 6) . Optimal load ammo type 6. 

SUPOFF (SUPPLY OFFICER). Of TANK. 

SYS .TYPE (SYSTEM TYPE). Of TANK. 

TWT (TRUCK WEIGHT). Maximum cargo weight for a vehicle. 
TCU (TRUCK CUBE). Maximum cargo cube for a vehicle. 

WPN. TYPE (WEAPON TYPE). Of TANK. 



GL OBA L VARIABLES (I NTE GER) 



WSTREAM (WEAPON RANDOM NUMBER STREAM). 



ARGU MENT (INT EGER) 



RND.CNTR (ROUND COUNTER). Argument of routine W. AMMO (WEAPON 



AMMUNITION) carrying the value of the TANK updating. 



PROGRAM LI STING 



1 ROUTINE BLU. CREATE 

2 » « 

3 DEFINE I AS AN INTEGER VARIABLE 

4 PRINT 1 LINE THUS 

ROUTINE BLU. CREATE 

5 • ' 

6 READ W MIN, WMAX, WSTREAM 

7 SKIP 2 CARDS 

8 READ PMIN, PMAX,PSTREAM 

9 SKIP 2 CARDS 

10 READ CMIN,CMAX,CSTREAM 
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1 1 

12 

13 

14 
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72 
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75 
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79 



SKI? 2 CARDS 

LIST WHIN, «MAX,WSTREAM,PMIN,PMAX, PST BEAM 
LIST CMIN,CMAX,CSTREAM 

• • 

READ CNUM.PNUM,SNUM 
SKIP 2 CARDS 
LIST PNUM,CNUM,SNUM 
CALL PARAMETERS 

LET N. COMPANY. COMMANDER = CNUM 
CREATE EVERY COMP ANY . COMMANDER 
FOR EVERY COM P ANY . COMM ANDER, DO 

READ N.CCL. V. ITEMS (COMPANY . COM MAN DER) 
READ S4. OFF (COMPANY. COMMANDER) 

LIST N.CCL. V. ITEMS (COMPANY. COMMANDER) 
LIST S4. OFF (COMPANY. COMMANDER) 

LOOP 

SKIP 2 CARDS 

LET N. PLATOON .LEADER = PNUM 
CREATE EVERY PLATOON . L EADER 
FOR EVERY PLATOON . LEADER , DO 
READ PCO.CDR (PLATOON. LEADER) 

READ N.PCL. V. ITEMS (PL ATOON . LEADER) 

LIST PCO.CDR (PLATOON. LEADER) 

LIST N.PCL. V. ITEMS (PLATOON. LEADER) 

FILE PLATOON. LEADER 

IN CO. UNIT (PCO.CDR (PLATOON. L EADE R) ) 

LOOP 

SKI? 2 CARDS 

LET N. SUPPLY. OFFICER = 5NUM 
CREATE EVERY SUPPLY. OFFICER 
FOR EVERY SUPPLY . OFFICER , DO 
READ SCO. CDR (SUPPLY. OFFICER) 

READ N. SCL. V. ITEMS (SUPPLY . OFFICER) 

LIST SCO. CDR (SUPPLY. OFFICER) 

LIST N.SCL. V. ITEMS (SUP PLY. OFFICER) 

SKIP 3 CARDS 
LOOP 

CALL BASIC. LOAD 
SKIP 2 CARDS 



READ N. TANKS SKIP 3 CARDS 

FOR I = 1 TO N. TANKS, DO 
CREATE A TANK 

READ NAME (TANK) , CO LOR (TANK) , SYS. TYPE (TANK) 
WPN.TYPE (TANK) ,AP. TOW (TANK), HE . DRAG (TANK) , 
AW1 .OR. MSL3 (TANK) , AW2.0R. ADM (TANK) , 



SLOAD3 (TANK) , 




K) 



,COCDR (TANK) .SUPOFF (TANK) 
, MAX. CUBS^ TANK) 



AMM05 (TANK) , AMM06 VTA NK) , 

SLOADT (TANK) ,SLOAD2 (TANK) , 

SLOAD4 (TANK) 

ON 1 (TANK 
OH 6 (TANK 
TAC4 (TANK) 

PLTLDR (TAN 
MAX. WT (TANK) 

IF SYS. TYPE (TANK) EQ 7, 

FILE TANK IN S . UNI T (SUPOFF (T ANK) ) 

always 

IF SYS. TYPE (TANK) NE 7 

FILE TANK IN PLAT. UNIT (PLTLDR (TANK) ) 
SCHEDULE AN UP . W . AMMO (TANK) IN 1 MIN 
ALWAYS 

FILS TANK IN TNK. ALIVE 
LET POINTER (TANK) =TANK 

K)= MAX. WT (TANK) 

MAX .CUBE (TANK) 



OH 5 (TANK) , 
(TANK) , 



UTE 



TCU (TAN! 



LET 

LET TWT (TANK) = 
SKIP 2 CARDS 
LOOP 
RETURN 
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80 END 



EXPLANATIO N O F CODE 

Line 3 Defines recursive variables for the routine. 

Line 4 Prints message to mark the start of the routine. 

Lines 6-13 Read and print out data establishing min and max 
times entities will check their ammo status as well as 
random number streams for calculations. 

Lines 15-17 Establish the number of company commanders, 
platoon leaders, and supply officers to be created in 
the simulation and print out the information input. 

Line 18 Calls routine PARAMETERS. 

Lines 19-27 Create the specified number of company 

commanders, and read the attributes of each and print 
the information. 

Lines 29-38 Create the specified number of platoon leaders, 
read their attributes, file them in appropriate sets and 
print the information. 

Lines 40-48 Create the specified number of supply officers, 
read their attributes, file them in appropriate sets and 
print the information. 

Line 49 Calls routine BASIC. LOAD. 
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Line 52 Reads the number of TANKS to be created for the 
simulation. 

Lines 53-78 Create the specified number of TANKS read their 
attributes, file them in appropriate sets and print the 
information . 

Line 71 Schedules an UP. W. AMMO event for each TANK to 
initially set ammunition status. 

D. ''ROUTINE PARAMETERS" 

Routine PARAMETERS is called from routine BLU. CREATE to 
reserve space for and read values into the following arrays: 
WPNLON , COMLON, NOMEN, ROF , POF, and POD. Additionally the 
critical cutoff values for supply action (C. L2WT, C.L2C, 
C.L2PCT, and C.L1PCT) , the trip times to and from the supply 
points (MINTRIP and MAXTRIP) , and the random number streams 
TSTREAM and RSTREAM are established. 

G109AL_7ARIABLES_iAL?HAl 

NOMEN (NOMENCLATURE) . Array specifying the name of rounds 
played . 

GLOBA L V ARIABLES (INTEGER) 

CNUM (COMPANY NUMBER). Specifies the number of 
COMPANY. COMMANDERS created. 
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RCODE (RESUPPLY CODE) (2-d). Holds the pointer value for a 
supply unit's SCL . V. ITEMS (SUPPLY CLASS V ITEMS). 

RO? (RATE OF FIRS) (2-d). Specifies the rates of fire for the 
six weapons of any weapon system. 

RSTREAM (RESUPPLY STREAM). Specifies the random number stream 
to be used for resupply calculations. 

TSTREAM (TRIP RANDOM NUMBER STREAM). 

GLOBAL V ARIAB LES (REAL) 

C. L1PCT (CRITICAL L0N1 PERCENTAGE). Holds the maximum 

percentage that LON1 requisitions may be reduced to in 
order to release space on a convoy for other critical 

V 

L0N1 and L0N2 requests. 

C. L2CU (CRITICAL L0N2 CUBE). Holds the maximum percent of 

cube L0N2 requisitions may be cut to in order to release 
space on a convoy for ether critical L0N1 and L0N2 
requisitions. 

C.L2PCT (CRITICAL L0N2 PERCENTAGE). Holds the maximum 

percentage that L0N2 requisitions may be reduced to in 
order to release space on a convoy for other critical 
L0N1 and L0N2 requests. 

C.L2.WT (CRITICAL L0N2 WEIGHT). Holds the maximum percent of 
cube L0N2 requisitions may be cut to in order to release 
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space or. a convoy for other critical L0N1 and L0N2 



requisitions. 



COMLON (2-d) (COMPANY LEVEL OF NEED) . 



MAXTRIP (MAX TRIP) . The maximum time required for a convoy to 



reach its intended destination. 



MINTRI P (MI N TRIP). The minimum time required for a convoy to 



reach its intended destination. 



PLTLON (2-d) (PLATOON LEVEL OF NEED). 



POD (2-d) (PROBABILITY OF DAMAGE) . For all weapon systems 



played . 



POF (2-d) (PROBABILITY OF FIRE). For all weapon systems 



played. 



WPNLON (2-d) (WEAPON LEVEL OF NEED). 



RE CURSIVE VAR IABL ES ( INTEGER) 



MAX. CL. V. ITEMS (MAX NUMBER OF CLASS V ITEMS PLAYED). 



N.WPN. TYPES(NUMBER OF WEAPON TYPES). 



PROGRAM_LISTING 



1 ROUTINE PARAMETERS 

2 • ' 

3 PRINT 1 LINE THUS 

ROUTINE PARAMETERS 

4 DEFINE MAX. CL . V. ITEMS, AND N.WPN. TYPES 

5 AS AN INTEGER VARIABLES 

6 READ MAX. CL. V. ITEMS 

7 LIST MAX. CL. V. ITEMS 

8 SKIP 3 CARDS 

9 ' • 

10 RESERVE WPNLON (*,*) AS M AX . CL . V. ITEMS BY 5 

11 READ WPNLON 

12 SKIP 3 CARDS 

13 LIST WPNLON 

14 RESERVE^ PLTLON (*,#) AS MAX. CL. V . ITEMS BY 5 

15 READ PLTLON 

16 SKIP 3 CARDS 
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17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 

56 

57 

58 



AS MAX. CL. V. ITEMS BY 5 



LIST PLTLON 
RESERVE COMLON (*,*) 

READ COMLON 
SKIP 2 CARDS 
LIST COMLON 
« • 

RESERVE NOMEN (*) AS MAX . CL . V . ITE MS 
READ NOMEN 

2 CARDS 
NO MEN 



N.WPN. TYPES 



SKIP 

LIST 

« « 

READ 

• • 

SKIP 3 CARDS 
RESERVE HOF AS 
READ ROF 
SKIP 3 CARDS 
LIST ROF 

t « 

RESERVE PO? AS 
READ POP 
SKIP 3 CARDS 
LIST POP 

• i 

RESERVE POD AS 
READ POD 
SKIP 2 CARDS 
LIST POD 

i « 

’•RESERVE AN ARRAY 
RESERVE RCODE (*,*) 

” SET OP CRITICAL 
READ 
LIST 
SKIP 
READ 
LIST 

SKIP 

« « 

RETORN 
END 



LIST N.WPN. TYPES 



N.WPN. TYPES BY 6 



N.WPN. TYPES BY 6 



N.WPN. TYPES BY 4 



TO 

AS 



HOLD 

CNOM 



RESOPPLY 
3Y 6 



REQUESTS 



CUTOFF VALUES FOR 
C. L2WT,C.L2CU,C.L2PCT,C.L1PCT 
C. L2WT,C.L2CU,C.L2PCT,C.L1PCT 
2 CARDS 

MINTRIP, MAXTRIP ,TSTREAM, RSTREAM 
MINTRIP , MAXTRIP ,TSTREAM,RSTREAM 
2 CARDS 



3-4 



EXPLANATION OF CODE 



Line 3 Prints a message specifying the start of the 



rout me. 



Lines 4-5 Define recursive variables for the routine. 

Lines 6-7 Read and print out the max number of ammunition 
rypes to be played in the simulation. 

Lines 10-21 Reserve space for and read the threshold values 
for the level of need played at the weapon, platoon, and 
company levels in the simulation. 
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Lines 23-26 Reserve an array for and read in the 
nomenclatures played. 

Line 28 Reads the number of weapon types played. 

Lines 31-44 Reserve space for, assign values to, and print 
out the arrays used in the battle computations. These 
arrays are: Rate of Fire; Probability of Fire; and 
Probability of Damage. 

Lines 46-47 Reserve space to hold values of resupply 

requisitions creared by each company in the simulation. 
Lines 49-51 Read in the critical cutoff values for resupply 
action. These values are: Critical LGN2 weight; 

Critical L0N2 cube; Critical L0N2 Percent; and Critical 
L0N1 percent. 

Lines 53-54 Read in the min and max times required to 
travel between the supply point and the company. 

E. "ROUTINE BASIC. LOAD" 

Routine BASIC. LOAD is called from routine BLU. CREATE to 
create the base ammunition assets of ail platoons, 
companies, and supply officers in the model. 

EVENTS CAL LED 

UP.COM. AMMO(UPDATE COMPANY AMMO). 

UP. PLT . AMMO (UPDATE PLATOON AMMO). 
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GL OBA L VARIABLES (ALPHA) 

NOMEN (NOMENCLATURE) . Specifies name of round. 

GLOBAL VARIABLES (INTEGER) 

CCODE (COMPANY CODE) (2-d). Holds the pointer value for a 
company's CCL. V. ITEMS (COMP ANY CLASS V ITEMS) . 

CNUM (COMPANY NUMBER). Specifies the number of 
COMPANY. COMMANDERS created. 

PCODE (PLATOON CODE) (2-d) . Holds the pointer value for a 
platoon's PCL. V. ITEMS (PLATOON CLASS V ITEMs). 

PNUM (PLATOON NUMBER). 

SCODE (SUPPLY CODE) (2-d). Holds the pointer value for a 
supply unit's SCL .V. ITEMS (SUPPLY CLASS V ITEMs). 

SNUM (NUMBER OF SUPPLY OFFICERS). 

PERMA NE NT ATT RIBU TES (INTEGER) 

N. CCL. V . ITEMS . Number of company class V items (UNIQUE TO A 
COMPANY. COMMANDER) . 

N. PCL. V. ITEMS. Number of platoon class V items(UNlQUE TO A 
PLATOON. LEADER) . 

N. SCL. V . ITEMS . Number of supply class V items (UNIQUE TO A 
SUPPLY. OFFICER) . 

RE CUR SIV E VA RIABLES (IN TEGER) 

C,I,P,S - Loop indicies. 

SET S U SED 
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CO. AM 3 0 (COMPANY AMMUNITION). Owned by a COMPANY. COMMANDER. 
Members are the unit's CCL . V. ITEMS (COMPA NY CLASS V 
ITEMS) 

PLT. AMMO (PLATOON AMMUNITION). Owned by a PLATOON . LEAD ER. 
Members are the unit's PCL . V. ITEMS (PLATOON CLASS V 
ITEMS) 

S. AMMO (SUPPLY AMMUNITION). Owned by a SUPPLY. OFFICES. 

Members are the unit's SCL . V. ITEMS (S UPPLY CLASS V ITEMS) 
TE MPOR ARY ENTITIES 
CCL. V. ITEM. (COMPANY CLASS V ITEM). 

PCL. V. ITEM. (PLATOON CLASS V ITEM). 

SCL. V. ITEM. (SUPPLY CLASS V ITEM). 

T EMPO RA RY A TTRIBUTE S ( ALPHA) 

C.RND.CNTR (COMPANY ROUND COUNTER). Argument for event 
UP. COM. AMMO (UPDATE COMPANY AMMUNITION) holding a 
pointer of a company unit. 

CNOMEN (COMPANY NOMENCLATURE). This attribute of a 

CCL. V. ITEM (COMPANY CLASS V ITEM) contains the name of 
the particular ammunition. 

PNOMEN (PLATOON NOMENCLATURE). This attribute of a 

PCL. V. ITEM(PLATOON CLASS V ITEM) contains the name of 
the particular ammunition. 
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SNOMEN (SUPPLY NOMENCLATURE). This attribute of a 

SCL. V. ITEM (SUPPLY CLASS V ITEM) contains the name of the 
particular ammunition. 

TE MPO RARY ATTRIBUTES (INTEGER) 

CAC (COMPANY AMMUNITION CODE). 

ONHAND (INTEGER). This attribute of a SCL. 7. ITEM (SUPPLY 

CLASS V ITEM) holds the on-hand balance of stocks for an 
ammunition . 

P.RND.CNTR (PLATOON ROUND COUNTER). Argument of the event 
UP. PIT. AMMO (UPDATE PLATOON AMMUNITION) carrying the 
pointer value of the platoon currently updating. 

PAC (PLATOON AMMUNITION CODE). Of a PCL . V .ITEM (PLATOON CLASS 
V ITEM) 

RDS. PKG (ROUNDS PER PACKAGE). Number packed per pallet of an 
SCL. V. ITEM (SUPPLY CLASS V ITEM). 

SAC (SUPPLY AMMUNITION CODE). 

TEMP ORA RY A TTRIBUTES 12 E AL l 

CU. PKG (CUBE PACKAGE). Cube of ammo pallet for an SCL. V. ITEM 
(SUPPLY CLASS 7 ITEM) . 

WT. PKG (WEIGHT PACKAGE). Weight of ammo pallet for an 
SCL. 7. ITEM (SUPPLY CLASS 7 ITEM). 

PROGRAM LIST ING 

1 ROUTINE BASIC. LOAD 

2 DEFINE I , P , S , AND C AS INTEGER 7 ARIABLES 
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3 


PRINT 1 LINS THUS 
ROUTINE BASIC. LOAD 


4 

5 

6 
7 
9 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 


« t 

"SETUP PLATOON 3ASIC LOADS 
RESERVE PCODE l*,*) AS PNUM BY * 

FOR P = 1 TO PNUM, DO 

RESERVE PCODE (PNUM ,* ) AS N . PCL . V . I TEMS (P) 

FOR I = 1 TO N. PCL. V. ITEMS (P) , DO 

CREATE A PCL. V. ITEM CALLED PCODE (P,I) 

LET PAC (PCODE (P,I) ) = I 

LET PNOMEN (PCODE (P,I) ) = NOMEN (I) 

FILE PCODE (P, I) IN Pi.T.AMMO(P) 

LOOP 

SCHEDULE A UP. PLT. AMMO (P) IN 1 MINUTE 

LOOP 

« • 

"SETUP COMPANY 3 ASIC LOADS 
RESERVE CCODE (*, *) AS CNUM BY * 

FOR C=1 TO CNUM, DO 

LIST C.CNUM.N. CCL. V. ITEMS (C) 

RESERVE CCODE (CNUM,*) AS N . CCL . V. ITEMS (C) 

FOR I = 1 TO N. CCL .V. ITEMS (C) , DO 

CREATE A CCL. V. ITEM CALLED C CODE (C, I) 

LET CAC (CCODE (C,I) ) = I 

LET CNOMEN (CCODE (C,I) ) = NOMEN (I) 

FILE CCODE (C, I) IN CO. AMMO (C) 

LOOP 

SCHEDULE AN UP . COM . A MMO (C) IN 1 MINUTE 
LOOP 

• « 

" SETUP SUPPLY OFFICER BASIC LOADS 
RESERVE SCODE (*,*) AS SNUM BY * 

FOR S=1 TO SNUM, DO 

LIST S, SNUM, N. SCI. V. ITEMS (S) 

RESERVE SCODE (SNUM ,#) AS N . SCL . V . I TEMS ( S) 

FOR I = 1 TO N.SCL.V. ITEMS (S) , DO 

CREATE A SCL. V. ITEM CALLED SCODE (S, I) 

LET SAC (SCODE (S, I) ) = I 

LET SNOMEN (SCODE (S, I)) = NOMEN (I) 

READ WT. PKG(SCODE(S,lh , CU . P KGjSCODE (S ,1 ) ) 
READ RDS. PKG (SCODE (S,I) ) .ONHAND (SCODi (S,I) ) 
FILE SCODE (S, I) IN S.AMMO(S) 

LOOP 

LOOP 

RETURN 

END 

EXPLANATION OF CODE 


Line 2 


Defines recursive variables used in the routine. 


Line 3 


Prints a message marking the beginning of the 



routine. 



Line 6 


Reserves the first index of the ragged array PCODE 


as 


the number of platoons played in the simulation. 
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PCODE will eventually hold the ammunition types used by 
the platoon. 

Line 7 Begins the outside loop over each Platoon . Leader for 
the code segment which creates and stores the ammunition 
carried by each platoon. Loop ends on line 16. 

Line 8 Reserves the second index of the ragged array PCODE 
to hold the number of ammo types carried by each 
platoon. 

Line 9 Begins the inside loop over each ammunition type 
carried by a platoon. Loop ends on line 14. 

LINE 10-13 Create each ammo type carried by a platoon, 
record its ammunition code and nomenclature, and file 
the ammo type in the platoon leader's aamo 
stocks (PLT. AMMO) . 

Line 15 Schedules the initial update for the platoon. 

Line 19 Reserves the first index of the ragged array CCODE 
to the number of companies played in the simulation. 
CCODE will eventually hold the ammunition types used by 
the company. 

Line 20 Begins the outside loop over each company 

commander, the code segment which creates and stores the 
ammunition carried by each company. Loop ends on line 
30. 



157 



Lins 22 Reserves the second index of the ragged array CCODE 
to hold the number of ammo types carried by each 
company. 

Line 23-28 Begin the inside loop over each ammunition type 
carried by a company. Loop ends on line 28. 

Line 24-27 Create each ammo type carried by a company; 
record its ammunition code and nomenclature; and fils 
the ammo type in the company ammo stocks (CO. AMMO) . 

Line 33 Reserves the first index of the ragged array SCODE 
no the number of supply elements played in the 
simulation. 

Line 34 Begins the outside loop over each supply officer, 
the code segment which creates and stores the ammunition 
carried by each supply unit. Loop ends on line 45. 

Line 36 Reserves the second index of the ragged array SCODE 
to hold the number of ammo types carried by each supply 
unit . 

Line 37 3egins the inside loop over each ammunition type 
carried by a supply unit. Loop ends on line 44. 

Lines 38-43 Create each ammo type carried by a supply unit; 
record its ammunition code, nomenclature, standard 
package weight, standard package cube, number of rounds 
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per package, starring level, and file them in the supply 
unit's ammo stocks (S . AMMO) . 

F. "ROUTINE W . AMMO" 

Routine W.AMMO is called by events UP. W.AMMO, 

CO. RESUPPLY. ARR, and REDISTRIBUTE for each TANK in the model 
in order to update each TANK'S ammunition LON. An argument, 
NO. BATTLE, is set to indicate whether battle information 
should be obtained or if only a simple update is required. 
Additionally a program indicator WFLAG, is set to provide 
information on the system's status. 

ARGUMENT S USE D 

A - Identifies the weapon system updating its ammunition. 

NO. BATTLE. Indicates whether routine BATTLE should be 
called. 

"0" indicates no 
"1" indicates yes 

WFLAG. Weapon status indicator. If WFLAG=100 the weapon is 
out of a particular ammunition this signals the platoon 
to do an immediate update. If WFLAG=1 the TANK has been 
knocked out of battle and should no longer update its 
ammunition status. 

DEFI NE T 0_ M E A N 

AMMO 1 . AP.TOW ( ARMOR PIERCING/TOW ROUNDS ) . 
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AMM02. HE. DRAG (HEAT/DRAGON ROUNDS). 

AMM03. AW 1. OR. MSL3 (ALTERNATE WEAPON 1 OR MISSILE 3). 

AMM04. AW 2. OR. ADM (ALTERNATE WEAPON 2 OR AIR DEFENSE 
MISSILE) . 

GL OBAL VARI ABLES 

WPNLON (2-d) (WEAPON LEVEL OF NEED) . 

PE RMAN E NT ATTRIBUTE (REAL) 

TIME. V 

RECURSI VE VARI ABLES (INTEGERS) 

I - Loop index. 

TEMP. LON (TEMPORARY LON). Place holder for LON computations. 
TRY Routing indicator to the ammo type being updated. 

RE CUR SI VE VAR IABLES (REAL) 

PCT (PERCENT) . 

ROUTINES CAL LED 

BATTLE 

TEM PORARY ATT RIBUTES (I NTE GER) 

AMM05 (AMMUNITION 5). Of a TANK. 

AMM06 (AMMUNITION 6). Of a TANK. 

AP. TOW (ARMOR-PIERCING/TOW) . Ammunition 1. 

TAC 1 . TANK AMMUNITION CODE 1. 

TAC2 . TANK AMMUNITION CODE 2. 

TAC3 . TANK AMMUNITION CODE 3. 
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TAC4 . TANK AMMUNITION CODE 4 



TAC5. TANK AMMUNITION CODE 5. 

TAC6. TANK AMMUNITION CODE 6. 

AW1 .OR . MSL3 (ALTERNATE WEAPON 1 OR MISSILE 3). Ammunition 3 
of a TANK. 

AW2. OR. ADM (ALTERNATE WEAPON 2 OR AIR DEFENSE MISSILE). 
Ammunition 4 of a TANK. 

FKILL (FIREPOWER KILL). Indicates whether a TANK has 

sustained a firepower kill during the battle. 

"O’ 1 indicates no 
"1" indicates yes 

HE. DRAG (HEAT/DRAGON ROUNDS). Ammunition 2 of a TANK. 

KKILL (CATASTROPHIC KILL). Indicates whether a TANK has 

sustained a catastrophic kill during the battle. 

"0" indicates no 
"I" indicates yes 

MKILL (MOBILITY KILL). Indicates whether a TANK has sustained 

a mobility kill during the battle. 

M 0" indicates no 
"1 '• indicates yes 

MFKILL (MOBILITY AND FIREPOWER KILL). Indicates whether a 

I 

TANK has sustained a mobility and firepower kill during 
the battle. 



"O'* indicates no 
"I" indicates yes 

0H1 (ON-HAND 1). Current balance of ammunition 1 on a TANK. 
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TANK . 



0H2 (ON-HAND 2). Current balance of ammunition 2 on a 

0H3 (ON-HAND 3). Current balance of ammunition 3 on a TANK. 

0H4 (ON-HAND 4). Current balance of ammunition 4 on a TANK. 

0H5 (ON-HAND 5). Current balance of ammunition 5 on a TANK. 

0H6 (ON-HAND 6). Current balance of ammunition 6 on a TANK. 

POINTER Machine address of a TANK. 



PLTLDR (PLATOON LEADER) Of TANK, 
SL0AD1 (STOWED LOAD 1) . Optimal 
SL0AD2 (STOWED LOAD 2). Optimal 
SLOAD3 (STOWED LOAD 3) . Optimal 
SL0AD4 (STOWED LOAD 4) . Optimal 
SLOAD5 (STOWED LOAD 5). Optimal 
SL0AD6 (STOWED LOAD 6) . Optimal 
WLON1 (WEAPON LEVEL OF NEED 1). 

WLON2 (WEAPON LEVEL OF NEED 2). 

WLON3 (WEAPON LEVEL OF NEED 3) . 

WLON4 (WEAPON LEVEL OF NEED 4). 

WLON5 (WEAPON LEVEL OF NEED 5). 

WL0N6 (WEAPON LEVEL OF NEED 6). 

TEMPORARY ENTITIES 



load ammo type 1. 
load ammo type 2. 
load ammo type 3. 
load ammo type 4. 
load ammo type 5. 
load ammo type 6. 

Urgency of need ammunition 1 
Urgency of need ammunition 2 
Urgency of need ammunition 3 
Urgency of need ammunition 4 
Urgency of need ammunition 5 
Urgency of need ammunition 6 



TANK 



PROGRAM LISTING 



1 ROUTINE W . AMMO GIVEN A, AND NO. BATTLE YIELDING WFLAG 
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2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 

56 

57 

58 

59 

60 

61 

62 

63 

64 

65 



DEFINE NO . 3ATTLE , WFL AG , TEMP .LON AS INTEGER VARIABLES 
DEFINE PCT AS A REAL VARIABLE 
DEFINE A. TRY, AND I AS AN INTEGER VARIABLES 
PRINT 2 LINES WITH TIME.V AND A AS FOLLOWS 
EVENT W. AMMO CALLED AT TIME. V **.**** 

WEAPON SYSTEM ****** OPDATING 

• i 

IF NO. BATTLE EQ 0, 

CALL BATTLE (A) 

ALWAYS 

IF FKILL(A) EQ 1 OR KKILL(A) EQ 1 OR MKILL(A) EQ 1 
OR MFKILL(A) EQ 1 

PRINT 2 LINES WITH POINTER (TANK) THOS 
3ATTLE DAMAGE ON TANK ****** PREVENTS 
AMMO ASSESSMENT. SEQUENCE ENDED. 

LET WFLAG =1 * * BATTLE DAMAGE SUSTAINED 

RETURN 
OTHERWISE 

• i 



"CAPTURE CURRENT INFORMATION FOR 



= AMMO 1 
= AMMO 2 (A 



A 
A 
A 
A 

A, 

A = AM MO 6 



= AMM03 
= AM MO 4 



= AMM05 /A 



LET OH1 
LET OH2 
LET OH3 
LET OH4 
LET OH5 
LET OH6 

i i 

"BEGIN LON COMPUTATIONS 
LET PCT= AMMO 1 (A) /SLOAD 1 (A) 
LET 1= TAC 1 (A) 

LET TRY = 1 
GO TO CHECK 

J 1 ' LET WLON1 (A)=TEMP.LON 

LET PCT= AMM02 (A)/SLOAD2 (A) 
LET 1= TAC 2 (A) 

LET TRY = 2 
GO TO CHECK 

* 2 ' LET WLON2 (A)=TEMP.LON 

it 



PLT. COMPUTATIONS. 



LET PCT= AMMO 3 (A) /SLOAD3 (A) 
LET 1= TAC3 (A) 

LET TRY = 3 
GO TO CHECK 

•3 'LET WLON3 (A) =TEMP .LON 

ti 



LET ?CT= AMM04 (A) /SLOAD4 (A) 
LET 1= TAC 4 (A) 

LET TRY = 4 
GO TO CHECK 

* 4 ' LET WLON4 (A)=TEMP.LON 

ii 

LET PCT= AMM05 (A) /SLOAD5 (A) 
LET 1= TAC5 (A) 

LET TRY = 5 
GO TO CHECK 

' 5 'LET WLON5 (A)=TEMP.LON 

ii 

LET PCT= AMM06 (A) /SLOAD6 (A) 
LET 1= TAC6 (A) 

LET TRY = 6 
GO TO CHECK 

* 6 ' LET WLON6 ( A) =TEMP .LON 
GO TO 7 

t t 

•CHECK' 

IF PCT GE WPNLON(I,1), 

LET TEMP. LON= 5 
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66 GO TO ROUTING 

67 ALWAYS 

68 • • 

69 IF PCT GE WPNLON(I,2), 

70 LET TEMP. LON= 4 

71 GO TO ROUTING 

72 ALWAYS 

73 • ' 

74 IF PCT GE WPNLON {1 , 3) , 

75 LET TEMP . LO N= 3 

76 GO TO ROUTING 

77 ALWAYS 

73 ' * 

79 IF PCT GE WPNLON (1,4) , 

80 LET TEMP . LO N= 2 

81 GO TO ROUTING 

82 ALWAYS 

83 • • 

84 IF PCT GE WPNLON (1,5) , 

85 LET TEMP . LON= T 

86 LET WFLAG = 100 

8 7 AL WAYS 

88 'ROUTING' GO TO 1,2,3, 4,5,6 PER TRY 

89 '7 • 

90 RETURN 

91 END 

EX PLAN A TION O F C ODE 



Lines 2-4 Define recursive variables used in the routine. 



Line 5 Prints a message marking the start of the event and 



identifying the weapon system updating. 



Lines 7-9 Check if battle information should be obtained. 



and call routine BATTLE to obtain this current 



information . 



Lines 10-15 Check if battle damage has been sustained. 



print a message if damage has been incurred and end the 



routine without action. 



Lines 17-23 Update the current knowledge of the ammo 



situation on the weapon system. 
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Lines 25-61 Sequentially address each ammo type carried on 
a weapon system; determine a percent fill; temporarily 
transfer control to * CHECK ' (line 63) in order to 
determine the correct LON to be assigned; and assign an 
LON. 

Lines 63-89 Receive a percent value from lines 25-61 and 
match this percent to that type of weapon's LON array. 
Pass the LON value determined back to lines 25-61 for 
assignment . 

G. "ROUTINE P. CLASS. V" 

Routine P. CLASS. V is called by events UP . PLT . AMMO , 

CO. RESUPPLY. ARR, and REDISTRIBUTE for each platoon played in 
the model to update their ammunition LONs according to the 
latest weapon LON information. Additionally, a program 
indicator, PFLAG, is set to provide information on the 
platoon's status. 

ARGUMENTS 

J - Argument for routine P. CLASS. V specifying the platoon 
currently updating. 

PFLAG. Platoon status indicator; 

PFLAG = 1 - indicates that the platoon is out of stock 
for an ammo type and signals the company to update its 
ammo status. 
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PFLAG = N.PCL.VITEMS - indicates that the platoon has no 
need for more ammo. That is, the platoon's weapons 
have been destroyed or damaged. 

GL OBA L VARIAB LES (INTEGER) 

PCODE (PLATOON CODE) (2-d) . Holds the pointer value for a 
platoon's PCL. V. ITEMS (PLATOON CLASS V ITEMS). 

TANK 

PLTLON (PLATOON LEVEL OF NEED) (2-d) . 

PE RMANENT AT TRIBUTES (REAL) 

TIME. 7 

PERMANE NT AT TRIBUTES (I NTE GER) 

N. PCL. 7. ITEMS. (NUMBER OF PLATOON CLASS V ITEMS). Unique to a 
PLATOON. LEADER. 

RECURSI VE V ARIABLES (INTEGER}. 

I - Loop index. 

RE CUR SI VE V ARIABLES (RE AL) 

PCT (PERCENT) . Place holder for calculations. 

RO UTIN E CA LLED 
P. CLASS. V 

SETS_USED 

PLAT. UNIT (PLATOON UNIT). Owned by a PLATOON . LEADER. Members 
are the unit's combat vehicles (TANKS) . 

TEMPORA RY ATT RIBUTES (INTEGER) 
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TAC 1 . TANK AMMUNITION CODE 1. 



TAC2. TANK AMMUNITION CODE 2. 
TAC3. TANK AMMUNITION CODE 3. 



TAC4 . TANK AMMUNITION CODS 4. 

TAC 5 . TANK AMMUNITION CODE 5. 

TAC6. TANK AMMUNITION CODE 6. 

FKILL (FIREPOWER KILL). Indicates whether a TANK has 

sustained a firepower kill during the battle. 

M 0" indicates no 
”1" indicates yes 

KKILL (CATASTROPHIC KILL). Indicates whether a TANK has 



sustained a catastrophic kill during the battle. 

”0** indicates no 
"I" indicates yes 

MFKILL (MOBILITY S FIREPOWER KILL). Indicates whether a TANK 
has sustained a mobility & firepower kill during the 



battle . 



*•0" indicates no 
”1” indicates yes 

MKILL (MOBILITY KILL). Indicates whether a TANK has sustained 

a mobility kill during the battle. 

"0" indicates no 
"1" indicates yes 

OH1 (ON-HAND 1) . Current balance of ammunition 1 on a TANK. 

OH2 (ON-HAND 2) . Current balance of ammunition 2 on a TANK. 

OH3 (ON-HAND 3). Current balance of ammunition 3 on a TANK. 
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0H4 (ON-HAND 4) . Current balance of ammunition 4 on a TANK. 

0H5 (ON- HAND 5) . Current balance of ammunition 5 on a TANK. 

0H6 (ON-HAND 6). Current balance of ammunition 6 on a TANK. 

P. SHORT (PLATOON SHORTAGE). Current shortage Of a PCL.V.ITEM 

(PLATOON CLASS V ITEM) . Unique to each platoon and ammo 
type. 

P.CMBT. LOSS (PLATOON COMBAT LOSS). Indicates that the loss of 
a platoon weapon system negates the need for this ammo 
type. 

PAM MO. LON(PLATCON AMMO LEVEL OF NEED). Unique for each 
platoon and ammo type. 

PCURR. LOAD (PLATOON CURRENT LOAD). On-hand balance of ammo. 

Unique for each platoon and weapon type. 

PL. 3. LOAD (PLATOON BASIC LOAD). Optimal load for a PCL.V.ITEM 
(PLATOON CLASS V ITEM) . 

SLOAD1 (STOWED LOAD 1) . Optimal load ammo type 1. 

SLOAD2 (STO WED LOAD 2) . Optimal lead ammo type 2. 

SLOAD3 (STOWED LOAD 3) . Optimal load ammo type 3. 

SL0AD4 (STOWED LOAD 4) . Optimal load ammo type 4. 

SL0AD5 (STO WED LOAD 5) . Optimal load ammo type 5. 

SLOAD6 (STOWED LOAD 6) . optimal load ammo type 6. 

PR OGR AM LISTI NG 

1 ROUTINE P. CLASS. V GIVEN J YIELDING PFLAG 
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2 

3 

4 

5 

6 

7 

3 

9 

10 

1 1 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 

56 

57 

58 

59 

60 

61 

62 

63 

64 

65 

66 

67 

68 



DEFINE I , PFLAG , AND J AS INTEGER VARIABLES 
DEFINE PCT AS A REAL VARIABLE 
PRINT 1 LINE WITH TIME.V AS FOLLOWS 

EVENT PLT.AMMO CALLED AT TINE. V #*.$**% 
FOR T = 1 TO N. PCL. V. ITEMS (J) , DO 

nrriDt) t n * n / r >r*n np /.T T\ \ = 



« « 



LET PCURR. LOAD (PCODE (J,I ) = 0 
LET PL. B.LOAD(PCODE(J,I) ) = 0 
FOR EVERY TANK IN PLAT. UNIT (J 
WITH MKILL (TANK) EQ 0 AND 
AND HFKILL (TANK) EQ 0, DO 



i.L 



KKILL (TANK) EQ 0 



t • 



• • 



• t 



1 1 



• • 



IF TAC1 (TANK) =1 

ADD OH1 (TANK) TO PCURR. LOAD (PCODE ( J ,1) ) 



$) T 0 



• ' NO FKILL 
PL. B. LOAD (PCODE ( J , I) ) 



IF FKILL (TANK) E 
ADD S LOAD 1 (TANK) 

ALWAYS 
GO TO SHORTAGE 
OTHERWISE 

IF TAC2 (TANK) =1 

ADD OH2 (TANK) TO PCURR. LOAD (PCODE (J, I) ) 

IF FKILL (TANK) EQ 0, 

ADD SLOAD2 (TAN K) TO PL. B . LOAD (PCODE ( J , I) ) 
AT WAY^ 

GO TO SHORTAGE 
OTHERWISE 

IF TAC3 (TANK) = I 

ADD OH3 (TANK) TO PCURR. LOA D (PCODE (J ,1) ) 

IF FKILL (TANK) EQ 0, 

ADD SLOAD3 (TANK) TO PL . B . LO AD (PCODE ( J , I) ) 
ALWAYS 

GO TO SHORTAGE 
OTHERWISE 

IF TAC4 (T ANK) =1 

ADD OH4 (TANK) TO PCURR. LOAD (PCODE (J, I) ) 

IF FKILL (TANK) EQ 0, 

ADD SLOAD4 (TANK) TO PL. B.LCAD (PCODE ( J , I) ) 
ALWAYS 

GO TO SHORTAGE 
OTHERWISE 

IF TAC5 (TANK) =1 

ADD OH5 (TANK) TO PCURR. LOAD (PCODE (J, I) ) 

IF FKILL (TANK) EQ 0, 

ADD SLOAD5 (TANK) TO PL. B . LOAD (PCODE ( J , I) ) 
ALWAYS 

GO TO SHORTAGE 
OTHERWISE 

IF TAC6 (TANK) =1 

ADD OH6 (TANK) TO PCURR. LOAD (PCODE (J ,1) ) 



IF FKILL(TANK) EC 
ADD 5LOAD6 (TANK) 



TO PL. B.LOAD (PCODE ( J , I) ) 

ALWAYS 
ALWAYS 

i i 

• SHORTAGE’ 

LET P. SHORT (PCODE ( J * I) ) = PL . B . LOAD ( PCOD E ( J ,1) ) 



LOOP 

i « 

’’CHECK FOR BATTLEDAMAGE 
I? 



- PCURR. LOAD (PCODE (J,i) ) 



PL. B. LOAD (PCODE (J 4 I) ) EQ 0, 

LET PFLAG = PFLAG+ 1 

LET P. SHORT (PCODE (J, I) ) = 0 

IF P.CMBT. LOSS (PCODE { J , I) ) EQ 0, 
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69 

70 


LET P.CMET. LOSS (PCODE (J, I) ) = 1 
PRINT 2 LINES WITH I, J THUS 

BATTLE DAMAGE HAS NEGATED THE NEED FOR 
AMMO IN PLATOON ** 


71 

72 

73 

74 

75 

76 

77 

78 

79 

80 
81 
82 
83 
34 

85 

86 

87 

88 

89 

90 

91 

92 

93 

94 

95 

96 

97 

98 

99 
100 


ALWAYS 

CYCLE 

OTHERWISE 

< t 

LET PCT= PC URR . LOA D (PCODE (J. I) ) 
/PL. B. LOAD (PCODE (J,I) J 

i i 

IF PCT GE PLTLON(I,1i, 

LET PAM MO. LON (PCODE (J, I) )=5 
CYCLE 
ALWAYS 

IF PCT GE PLTLON (1,2), 

LET PAMMO. LON (PCODE (J,I) ) =4 
CYCLE 
ALWAYS 

IF PCT GE PLTLON (1,3) , 

LET PAMMO. LON (PCODE (J, I) ) =3 
CYCLE 
ALWAYS 

IF PCT GE PLTLON (1 ,4) , 

LET PAMMO. LON (PCODE (J, I) ) =2 
CYCLE 
AL WAYS 

IF PCT GE PLTLON (I ,5) , 

LET PAMMO. LON (PCODE (J,I) ) =1 
LET PFLAG = 100 
ALWAYS 
LOOP 
RETURN 
END 

EXPLANATION OF CODE 


Lines 2- 


-3 Define recursive variables used in the routine. 


Line 4 


Prints out a message to mark the start of the 



routine. 

Line 5 Starts the outside loop over all the ammo types 
carried by the platoon. Loop ends on line 98. 

Lines 6-7 Zero out the platoon on-hand ammunition and basi 
load ammunition for the update. 

Lines 9-10 3egin the inner loop over all TANKS in the 

platoon in order to obtain the most current information 
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available on each TANK. The loop ends on line 62. 

Note: the information obtained from each TANK is 
"current knowledge" from its on-hand attributes. This 
is what the TANK "knows" it has on-hand. Opposite to 
this is "perfect knowledge" from its AHMO 1-AMao6 
attributes, which is what the TANK actually has on-hand. 

Lines 12-57 Cycle the index over the six possible choices 
on rhe TANK until identification or lack of 
identification of the ammo code being considered is 
made. If identification is made, the on-hand balance of 
rhe TANK’S known load is added to the platoon balance. 

If the weapon system is not F-KILLed the base load of 
the TANK'S ammo is added to the platoon base load. Base 
load is used in determining how much should be ordered. 
If the weapon has been F-KILLed the weapon's base load 
is ignored. This lowers the amount of ammo the platoon 
needs to have on-hand to keep its systems full. After 
updating, control is transferred to the shortage loop, 
lines 59-60 

Lines 59-61 Provide a running update of the amount of ammo 
the platoon is short as the update continues over ail 
the weapon systems in the platoon. 
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Line 62 Closes the loop for a TANK, transferring control 

either to line 8 to evaluate the next TANK for this ammo 
type or out to complete the LON computation for the ammo 
type. 

Lines 64-73 Check for a zero base load balance in the 
platoon's ammo. A new zero balance indicates that 
battle damage to platocn weapons has negated the need 
for further requisitioning of that type of ammo. A 
message is printed identifying the round type. Purther 
requisitions for this ammo type would not be made. 

Lines 75-76 Compute the percentage of fill (on-hand/base 
load) for an ammo type. 

Lines 78-97 Cycle the percentage over the five possible LON 
threshold values until the correct value is found and 
assigned. 

Line 98 Closes the major loop in the routine and transfers 
control back to line 5 in order to update the next ammo 
type. 

H. "ROUTINE COM. AMMO" 

Routine COM. AMMO is called by events UP.COM. AMMO and 

CO. RESUPPLY. ARE for each company played in the model to 

update ammunition LONs according to the most recent platoon 
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LON inf ormation . An argument, NO. BATTLE, is set to indicate 
whether RES.REQs should be filed or whether a simple update 
is sought. Additionally, a program indicator, CFLAG , is set 
to provide information on the system's status. 

ARGUMENTS_USED 

C - Argument of COM. A MMO (COMPANY AMMUNITION) holding the 
pointer value of the company currently updating. 

CFLAG. Company status indicator; CFLAG = N. CL. V. ITEM 

indicates that the company has no need for ammunition. 
That is, the company's weapons have been damaged or 
destroyed. 

NO . 3ATTLE. Indicates whether RES.REQs should be filed. 

”0" indicates no 
"1” indicates yes 
EVENTS S CHEDU LED 

UP. S4. AMMO (UPDATE S-4 AMMUNITION). 

G L 0 B A L _ V A R I AB L ES _± A L P H A). 

NOMEN (NOMENCLATURE) . Specifies name of round. 

GL OBA L VARIABLES (INTEGERS) 

CCODE (COMPANY CODE) (2-d) . Holds the pointer value for a 
company's CCL. V. ITEMS (COMPANY CLASS V ITEMS). 

PCODE (PLATOON CODE) (2-d). Holds the pointer value for a 
platoon's PCL.V.ITEMs(PLATOON CLASS V ITEMS). 

PLATOON. LEADER 
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RCODE (RESUPPLY CODE) (2-d). Holds the pointer value for a 
resupply unit's SCL. V. ITEMS (SUPPLY CLASS V ITEMS). 
TSTREAM (TRIP RANDOM NUMBER STREAM) 

COMLON (2-d) (COMPANY LEVEL OF NEED) . 

GL OBA L VARIA BLES (REAL) 

MAXTRIP (MA X TRIP). The maximum time required for a convoy to 
reach its intended destination. 

MINTRI P (MIN TRIP). The minimum time required for a convoy to 
reach its intended destination. 

PERMANENT AT T BI3UTES ( REAL l 

TIME. V 

PE RMA NE NT ATT RIBUTES (INTEGER) 

N.CCL. V. ITEMS (NUMBER OF COMPANY CLASS V ITEMS). Unique to a 
Unit. 

REQN (REQUISITION) . 

S4. OFF (Company S-4 OFFICER). 

RE CUR SI VE VA RIABLES (INTEGER), 

COUNT. Indicates if a resupply requisition has been filed. 

I - Loop index. 

RECURSIVE VARIABLES (REAL) 

PCT (PERCENT) . 

RO UTI NES CALLED 
UNIFORM. F 
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SETS USED 



CO. UNIT (COMPANY UNIT). Owned by a COMPANY. COMMANDER. 

Members are the unit's PLATOON . LEADERS. 

CWANT. LIST (COMPANY WANT LIST). Contains a listing of the 
resupply requests outstanding for the company. 

TEMP O R A RY E NTITI E S 

RES. REQ (RESUPPLY REQUEST). 

TE MPORARY_ ATT RIB UTES_ £ ALPHA). 

RNOMEN (RESUPPLY NOMENCLATURE). 

TE MPO RA RY A TTRIBUTES f INTEGER) 

C.CMBT. LOSS (COMPANY COMBAT LOSS). Indicates that the loss of 
a company weapon system negates the need for this ammo 
type. 

C.NUM. REQN (NUMBER OF COMPANY REQUISITIONS). Total number of 
RES.REQs submitted for an SCL. V.ITEM. 

c. SHORT (COMPANY SHORTAGE). Total rounds short for a type 
ammo. 

CAM MO. LON (COMP ANY AMMUNITION LEVEL OF NEED). 

CCURR. LOAD (COMPANY CURRENT LOAD). On-hand balance for an 
ammo type. 

CO. B. LOAD (COMP ANY BASIC LOAD). Optimal load for am ammo 
type. 
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ISSUES. Argument of UP. S4. AMMO (UPDATE. S4 .AMM UNITION) holding 
the pointer of the requesting unit. 

ISSUER. Argument of UP. S4 . AMMO (UPDATE. S4 . AMMUNITION) holding 
the pointer of the unit supply officer. 

PCURR. LOAD (PLATOON CURRENT LOAD). On-hand balance for an 



ammo type. 

PL. B. LOAD (PLATOON BASIC LOAD). Optimal load for an ammo 



type. 

RAC (RESUPPLY AMMO CODE). Of a RES. REQ (RESUPPLY REQUEST). 
REQUESTOR. Of a RES . R EQ (RESU PPLY REQUEST). Contains the 
pointer of the unit requesting. 

RQT Y (REQUIRED QUANTITY). Of a RES. REQ (RESUPPLY REQUEST). 



SPRIORITY (SUPPLY PRIORITY). Of a RES . REQ (RES UPPL Y REQUEST). 

TEMPORA RY ATT RIBUTES (REAL) 

TIME. Of creation of request. 



1 

2 

3 

4 

5 

6 

7 

8 
9 

10 
1 1 
12 

13 

14 

15 

16 

17 

18 
19 



PROGRAM LISTING 



ROUTINE COM. AMMO GIVEN C, NO. BATTLE YIELDING CFLAG 
DEFINE NO.BATTLE,I,COUNT,CFLAG,AND C 
AS INTEGER VARIABLES 
DEFINE PCT AS A REAL VARIABLE 
PRINT 1 LINE WITH TIME.V AS FOLLOWS 
EVENT COM. AMMO CALLED AT TIME.V 

t i 

FOR 1 = 1 TO N. CCL.V. ITEMS (C) , DO 
LET CCURR.LOAD (CCODE <C,I) ) = 0 
LET CO.B.LOAD(CCODE(c,I) ) = 0 
FOR EVERY P L ATOON . LE ADER IN CO . UNIT (C) , DO 
ADD PCURR . LOAD (P CO DE (PLATOON . LEADER , I) ) 

TO CCURR .LOAD (CCODE (C,I) ) 

ADD PL. 3. LOAD (PCODE (PLATOON. LEADER, I) ) 

TO CO. B. LOAD (CCODE (C,I) ) 

LOOP 

I? CO . B. LOAD (CCODE (C, I) ) = 0, 

LET CFLAG = CFLAG + 1 
IF C. CM3T. LOSS (CCODE (C,I) ) = 0 

LET C.CM3T. LOSS (CCODE (C,I) ) = 1 
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20 

21 

22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 

56 

57 

58 

59 

60 

61 

62 

63 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 

81 

82 

83 

84 

85 

86 



^BATTLE^IfG^IL^EGATErTHE NEED FOR 
AMMO IN COMPANY 
ALWAYS* 

CYCLE 

LST E pCT=CCUfiR. LOAD (CCODE (C.D) 



/CO . B. LOAD (CCODE (C , I) ) 

PCT GE COfoON (1,1), 

LET CAMMO . LON ^CCODE (C, I) ) -5 



GO TO SHORTAGE 
ALWAYS 



IF " PCT GE COMLON(I,2) 
LET CAMMO .LON (CCODE 
GO TO SHORTAGE 



'(C,I) ) =4 



'(C,I) ) =3 



IF W PCT GE COMLON (1 ,3) 

LET CAMMO. LONJCCODE 
GO TO SHORTAGE 
at W AY s 

IF I.i5 T CAMO?LO°“<5c6DV(C,I))=2 

GO TO SHORTAGE 
AT W AY S 

IF PCT GE COMLON (I ,5^, 

LET CAMMO. LON (CCODn (C,I) ) -1 
ALWAYS 

!i?°C?SHOSTlCCODE(C,I>) = £°c?uls“iAD < (CC<5Dj I ( ) C l , I)) 

I 

• ? "'check if resupply needed battle SQ 1 

IF CAMMO . LON (CCODE (C ,1) ) Gn 5 OR NO.BAll- V 
GO TO LOOP1 
OTHERWISE 



PRIOR LON IS EQUAL TO THE CURR LON, CYCLE. 




GO TO LOOP 1 
OTHERWISE 
• LOOP3 • LOOP 

••ORDER THE AMMUNITION 
CREATE A RES.REQ CALLED RCODE(C,I) 
LET COUNT = 1 
LET RE 
LET R? - 
LET ROTY 



UNT = » 

ENCODE (C.I) ) 

LET STATUS (RCODEjC, I) ) - 'T nc:u 
LET 3AC (RCODE (C, J.) ) = I_ „ 



LET 

LET 

LET 




C0S4" 

= N ° U Ca1mI. LON (CCODE (C,I) ) 



LET REQN(C) = REQN(C) + 1 
LET C.NUM.REQNjcCODE (C,I) ) - 

_-?A.»a«A.5I9S <5P°?g ‘S&RA.txs 



U.Nun. nay « vw-Ol, - ..... 

FILE RCODE (C ,1) IN C WANT. LIST (C) 

« 

LOOP 1 ’ LOOP 

I 

? SCHEDULE UP. S4 .AMMO (S4 . OFF (C) , C) 
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87 IN UNIFORM. F (MINT RIP, MAX TRIP, TSTH SAM) MINUTES 
89 ALWAYS 

89 RETURN 

90 END 

EX PLANA TIO N OF CODE 

Lines 2-4 Define recursive variables used in the routine. 

Line 5 Prints out a message to mark the start of the 
routine. 

Line 7 Starts the outside loop over all the ammo types 
carried by the company. Loop ends on line 83. 

Lines 8-9 Zero out the company on-nand ammunition and basic 
load ammunition for the update. 

Lines 10-15 3egin an inner loop over all platoons in the 
company in order to obtain the most current on-hand and 
base load information available in each platoon. The 
loop ends on line 15. Note: the information obtained 
from each platoon is "current knowledge", which is what 
the platoon knows it has on-hand, as opposed to "perfect 
knowledge", which is what the platoon actually has 
on- hand. 

Lines 16-23 Check for a zero base load balance in the 

company’s ammo. This would indicate that battle damage 
to company weapons has negated the need for further 
requisitioning of that type of ammo. A message is 
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printed identifying the round type. Further requisitions 
would not be made. 

Line 24-25 Compute the percentage of f ill (o r-hand/base 
load) for an ammo type. 

Lines 26-45 Cycle the percentage over the five possible LON 
threshold values until the correct value is found and 
assigned. Control is then directed xo lines 47-49 to 
determine the unit shortage. 

Lines 47-49 Provide an update of the total amount of ammo 
the company is short. 

Lines 51-55 Check if an initial ammo request needs to be 
filed. Ammunitions with LON values equal to 5 are 
cycled. Additionally, a NO. BATTLE check is made. 

NO. BATTLE equal to 1 indicates that a simple update is 
required and no RES.REQs are to be submitted. 

Lines 57-64 Check any previous requisitions for the ammo 
type being reviewed. If xhe previous request has a 
priority equal to the current LON there is no need for a 
new request to be filed and the routine is cycled. 

Lines 66-30 Create a requisition to be forwarded to 

battalion supply. The attributes set in the request 
are: requestor identification; a request poinxer; a 
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requested quantity; a reguest status; a request ammo 
code pointing to a particular ammo type; a reguest 
nomenclature; a request priority; time submitted; and 
total requests submitted for that ammo type. 

Line 81 Files the request in the company's want list. 

Line 83 Closes the major loop in the routine and transfers 
control to Line 7 to begin a loop over the next ammo 
type. 

Lines 85-88 The variable COUNT keys the fact that a 

requisition has been created and must be forwarded to 
battalion. If appropriate, an UP. 54. AMMO is scheduled. 

I. "ROUTINE BATTLE" 

Routine BATTLE is called from routine W. AMMO to obtain 
the most recent expenditure and damage information. The 
routine generates ammunition expenditures for each alive 
weapon according to designated rates of fire and 
probabilities of fire. It also randomly damages and 
destroys vehicles according to user designated probabilities 
of damage. 

AR GUM ENT S USE D 

A - Holds the value of the weapon system updating its 
sit uat ion . 

DEFINE TO M EAN 



180 



AMMO 1 . AP. TOW (ARMOR PIERCING/TOW ROUNDS). 

AMH02. HE. DRAG (HEAT/DRAGON ROUNDS). 

AMM03. AW1 .OR. MSL3 (ALTERNATE WEAPON 1 OR MISSILE 3). 

AiMMOU. AW2.0R. ADM (ALTERNATE WEAPON 2 OR AIR DEFENSE 
MISSILE) . 

GLOBAL V ARI ABLES (INTEGER) 

EOF (RATE OF FIRE) (2-d). Specifies the rates of fire for the 
six weapons on board any weapon system. 



RSTREAM (RESUPPLY STREAM). 

WSTREAM (WEAPON RANDOM NUMBER STREAM). 



GL OBA L VARIABL ES (REAL) 



B. END (BATTLE END). Termination time of daily battle. 

B. START (BATTLE START). Start time of daily battle. 

POD (2-d) (PROBABILITY OF DAMAGE). For all weapon systems. 
POF (2-d) (PROBABILITY OF FIRE). For all weapon systems. 
PERMA NENT ATT RIBUTE (REAL) 

TIME. 7 



RECURSIVE VARIABLES (REAL) 



LAM1 (LAMBDA 1). Holds the value of the 
for AMM0 1 from the POF (PRO BAEILITY 
LAM2 (LAMBDA 2). Holds the value cf the 
for AM MO 2 from the POF (PROBABILITY 



probability of fire 
OF FIRE) array, 
probability of fire 
OF FIRE) array. 
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LAM3 (LAMBDA 3). Holds the value cf the probability of fire 
for AM MO 3 from the POF (PROBABILITY OF FIRE) array. 

LAM4 (LAMBDA 4). Holds the value of the probability of fire 
for AM MO 4 from the POF (PROBABILITY OF FIRE) array. 

LAMS (LAMBDA 5). Holds the value of the probability of fire 
for AM MO 5 from the POF (PROBABILITY OF FIRE) array. 

LAM6 (LAMBDA 6). Holds the value cf the probability of fire 
for AMM06 from the POF (PROBABILITY OF FIRE) array. 

ROUTINE S CAL LED 

EXPONENTIAL.?, MAX.F, and RANDOM. F . 

SETS 

TNK. ALT VE (TANK ALIVE). Owned by the system. Members are 
vehicles still alive within the simulation. 

TEMPORARY ATTRIBUTES (INTEGER) 

AMM05 (AMMUNITION 5). Of TANK. 

AMM06 (AMMUNITION 6). Of TANK. 

AP. TO W ( ARMOR- PIERCING/TOW) . Ammunition 1 of TANK. 

AW1.0R.MSL3 (ALTERNATE WEAPON 1 OR MISSILE 3). Ammunition 3 
Of TANK. 

AW2. OR . ADM (ALTERNATE WEAPON 2 OR AIR DEFENSE MISSILE). 
Ammunition 4 of TANK. 
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FKILL (FIREPOWER KILL). Indicates whether a TANK has 
sustained a firepower kill during the battle. 



"0" indicates no 
"1" indicates yes 

HE. DRAG (HEAT/DRAGON HOUNDS). Ammunition 2 Of TANK. 

KKILL (CATASTROPHIC KILL) . Indicates whether a TANK has 

sustained a catastrophic kill during the battle. 

"0" indicates no 
"1" indicates yes 

MFKILL (MOBILITY & FIHEPOWEH KILL) . Indicates whether a TANK 
has sustained a mobility and firepower kill during the 
battle . 



"O" indicates no 
"I" indicates yes 

MKILL (MOBILITY KILL). Indicates whether a TANK has sustained 



a mobility kill during the battle. 



"O" indicates no 
M 1 M indicates yes 
POINTER. Machine address of TANK. 



WPN. TYPE (WEAPON TYPE). Of TANK. 



PR OGR AM LIS TING 



1 ROUTINE BATTLE (A) 

2 DEFINE A AS AN INTEGER VARIABLE 

3 DEFINE LAM1,LAM2,LAM3,LAM4, 

4 LAM5 , AND LAM6 AS REAL VARIABLES 

5 " 

6 "CHECK IF BATTLE IN PROGRESS, IF NOT, RETURN 

7 PRINT 1 LINE WITH E. START AND 3. END AS FOLLOWS 

BST ART = **.**** B . END = *#.*#** 

8 IF TIME . V LT B. START OR TIME.V GT B. END, RETURN 

9 OTHERWISE 
10 • ' 

11 " ESTABLISH RATE OF FIRE FOR EACH AMMUNITION FIRED. 

12 LET LAM 1 = ROF (W PN . T YPE ( A) , 1 ) 
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13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 
27 
23 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 
4 1 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 

56 

57 

58 

59 

60 
61 
62 

63 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 



Lines 2 



LET LAM2 = HOF (WPN . T YP E ( A) , 2) 

LET LAM3 = ROF (WPN . T YP E ( A) , 3; 

LET LAM 4 = ROF (WPN . TYPE (A) ,4 i 
LET LAM5 = ROF (WPN . TYPE (A , 5) 

LET LAM6 = ROF (WPN . T YPE ( A) ,6) 

i • 

" ESTABLISH AMMUNITION EXPENDITURES FOR EACH AMMO 
IF RANDOM. F (RSTREAM) LE POF ( WPN . TYPE (A) , 1 ) 

LET AMMO 1 (A) = M AX . F ( AMM0 1 ' ‘ ‘ 

- EXPONENTIAL. F 

AL WAYS 

IF RANDOM. F (RSTREAM) LE POF (WPN . TYPE (A) , 2) 

LET AMM02 (A) = M AX . F (AMM02 (A) 

- EXPONENTIAL. F (LAM2-*TIME.V , WSTREAM) ,0) 

AL WA YS 

IF RANDOM. F (RSTREAM) LE POF (WPN . TYPE (A) , 3) 

LET AMM03 (A) = MAX .F JAMM03 (A) 

- EXPONENTIAL. F (LAM3*TIME. V , WSTREAM) ,0) 

AL WAYS 

IF RANDOM. ? (RSTREAM) LE POF (WPN . TYPE (A) , 4) 



JlIm 1* 



I’i'TIME. V , WSTREAM) ,0) 



LET A MM04 (A) = MAX . F ( AMM04 (A) 


ALWAYS 



- EXPONENTIAL. F 



IF RANDOM. F (RSTREAM) LE POF (WPN . TYPE (A) , 5) 
LET A MM05 (A) = MAX . F (AMM05 (A‘ 

- EXPONENTIAL. F 

AL WAYS 

IF RANDOM. F (RSTREAM) LE POF (WPN . TYPE (A) , 6) 



4*TIME.V , WSTREAM) , 0) 
(A) 

(LAM 5* TIME. V , WSTREAM) , 0) 



LET A MM06 (A) = M AX . F (AMM06 (A) 

~(LAM6^TIME. V, WSTREAM) , 0) 



- EXPONENTIAL. F 



ALWAYS 

i t 



"DETERMINE IF DAMAGES HAVE BEEN SUSTAINED 
IF RANDOM. F (RSTREAM) LE POD ( WPN . TYPE (A) , 1 ) 
LET MKILLJA) = 1 
PRINT 1 LINES THUS 

BATTLE DAMAGE SUSTAINED 
LIST POINTER (A) , MKILL (A) 

AL WA YS 

IF RANDOM. F (RSTREAM) LE POD (WPN . TYPE (A) , 2) 
LET FKILLjA) = 1 
PRINT 1 LIN iS THUS 

BATTLE DAMAGE SUSTAINED 
LIST POINTER (A) , FRILL (A) 

AL WA V S 

IF RANDOM. F (RSTREAM) LE POD (WPN . TYPE (A) , 3) 
LET MFKILL(A) = 1 
PRINT 1 LINE THUS 

BATTLE DAMAGE SUSTAINED 
LIST POINTER (A). MFKILL (A) 

REMOVE A FROM TNK. ALIVE 
ALWAYS 

IF RANDOM. F (RSTREAM) LE POD (WPN. TYPE (A) , 4) 
LET KKILLjA) = 1 
PRINT 1 LINE THUS 

BATTLE DAMAGE SUSTAINED 
LIST POINTER (A) ,KKILL(A) 

REMOVE A FROM TNK. ALIVE 
ALWAYS 
RETURN 
END 

EX PLA NAT ION OF CODE 



-4 Define recursive variables used in the routine. 
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Lines 6-9 Check if a battle is currently in progress, if 
not it causes the routine to return without action. 

Lines 11-17 Assign a rate of fire by weapon and ammunition 
type for the six ammo types carried by the weapon 
updating. Rates of fire are obtained from a rate of fire 
array input by the user. 

Lines 19-43 Establish ammo expenditures for each of the six 
ammo types carried by a weapon system. Use of the weapon 
during the time period is established by comparing a 
random number to a probability of fire for the weapon 
system. Expenditure of ammo is then computed through the 
use of an exponential function using the weapon's rate 
of fire as lambda. 

Lines 45-71 Determine if battle damage has been sustained 
during the time period. Evaluation is made by comparing 
a random number against the various types of kill 
possible. 

J. "ROUTINE UP. DATE" 

Routine UP. DATE is called from event 3. UP. DATE and is 
used to print a battle summary listing weapon and unit 
assets, as well as supply status. 

GL OBA L VARIABLES (INTEGER) 
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CCL. 7. ITEM (COMPANY CLASS V ITEM). 

COMPANY. COMMANDER 
CONVOY 

CNUM (COMPANY NUMBER). Specifies the number of 
COMPANY. COMMANDERS created. 

PCL.V. ITEM (PLATOON CLASS V ITEM). 

PLATOON. LEADER 

PNUM (PLATOON NUMBER). 

RES .REQ. (RESUPPLY REQUEST). 

SCL. V. ITEM . (SUPPLY CLASS V ITEM). 

SNUM (NUMBER OF SUPPLY OFFICERS). 

SUPPLY. OFFICER 
T.CGO (TRUCK CARGO) . 

TANK 

PE RMAN EN T ATT RIBUTES 

TIME. V 

RECURSI VE V ARIABLES 
I, J, K - Loop indicies. 

SETS 

CARGO 

CO. AMMO (COMPANY AMMUNITION). Owned by a COMP ANY. COMMANDER . 
Members are the unit's CCL . V . ITEMS (COMPANY CLASS V 
ITEMS) . 
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CWANT. LIST (COMPANY WANT LIST). 

PLAT . UNIT(PLATOON UNIT). Owned by a PLATOON. LEADER. Members 
are the unit’s combat vehicles (TANKS) . 

PLT. AMMO (PLATOON AMMUNITION). Owned by a PLATOON . LEA DER. 
Members are the unit’s PCL.V. ITEMS (PLATOON CLASS V 
ITEMS) . 

S. AMMO (SUPPLY AMMUNITION). Owned by a SU PPLY . OFF ICER . 

Members are the unit’s SCL . V. ITEMS (SUPPLY CLASS V 
ITEMS) . 

S. UNIT (SUPPLY UNIT). Owned by a SUPPLY. OFFICER. Members are 
the unit's supply vehicles (TANKS) . 

SCONVOY (SUPPLY CONVOY). 

SREQN. LIST (SUPPLY REQUISITION LIST). 

SWANT. LIST (SUPPLY WANT LIST). Owned by a SUPPLY. OFFICER. 

Members are RES. REQs (RESUPPLY REQUESTS) from the combat 
units. 

TNK. ALIVE(TANK ALIVE) . 

TE MPO RARY ATTRIBUTES _ .(I NTEGER) 

SYS. TYPE (SYSTEM TYPE). 

PROGRAM LIST ING 

1 ROUTINE UP. DATE 

2 DEFINE I , J , AND K AS INTEGER VARIABLES 

3 PRINT 3 LINES WITH TIME.V AS FOLLOWS 

• t 

ROUTINE UP. DATE CALLED AT **.*##% 

• t 

4 « • 

5 LIST ATTRIBUTES OF EACH COMPANY . COMM ANDER 



187 



6 FOR J = 1 TO CNUM, DO 

7 LIST ATTRIB DTES OF EACH CCL.V.ITEM IN CO.AMMO(J) 

8 LIST ATTRIBUTES OF EACH RES. REQ IN CWA NT. LI ST (J) 

9 LOOP 

10 » • 

11 LIST ATTRIBUTES OF EVERY PLATOON . LEADER 

12 FOF. I = 1 TO PNUM, DO 

13 LIST ATTRIBUTES OF EACH PCL.V.ITEM IN PLT.AMMO(I) 

14 LIST ATTRIBUTES OF EACH TANK IN PLAT. UNIT (I) 

15 LOOP 

16 « » 

17 LIST ATTRIBUTES OF EVERY SUPPLY. OFFI CER 
13 FOR K = 1 TO SNUM, DO 

19 LIST ATTRIBUTES OF EACH SCL.V.ITEM IN S.AMMO(K) 

20 LIST ATTRIBUTES OF EACH RES. REQ IN SWA NT . LI ST (K) 

. 21 LIST ATTRIBUTES OF EACH RES. REQ IN SREQN. LIST (K) 

22 LIST ATTRIBUTES OF EACH CONVOY IN SCONVOY(K) 

23 LIST ATTRIBUTES OF EACH TANK IN S.UNIT(K) 

24 LOOP 

25 »• 

26 FOR EACH TANK IN TNK. ALIVE 

27 WITH SYS. TYPE (TANK) EQ 7. DO 

28 LIST ATTRIBUTES OF EACH T.CGO IN CARGO (TANK) 

29 LOOP 

30 '• 

31 PRINT 2 LINES WITH TIME.V AS FOLLOWS 

t « 

ROUTINE UP. DATE ENDED AT *♦.*¥** 

32 RETURN 

33 END 

EX PLA NAT ION O F CODE 



Line 2 Defines recursive variables for the routine. 



Line 3 Prints a message marking the start of the routine 



Lines 5-9 Mark a loop over the attributes and sets 



belonging to each company commander. 



Line 5 Lists attributes of each company commander. 



Line 7 Lists attributes of each class V item the company 



commnander owns. 



Line 8 Lists attributes of each resupply request the 



company commander has outstanding. 



Lines 11-15 Mark a loop over the attributes and sets 



belonging to each platoon leader. 



Line 11 Lists attributes of each PLATOON. LEADER . 
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Line 13 Lists the the attributes of each class V item the 
platocn leader owns. 

Line 14 Lists the attributes of each weapon system of the 
unit . 

Lines 17-24 Mark a loop over the attrioutes and sets 
belonging to each supply officer. 

Line 17 Lists the attributes of each supply officer 

Line 19 Lists the attributes of each class V item 

Line 20 Lists the attributes of outstanding requests from 

supported companies. 

Line 21 Lists the attributes of outstanding requests sent 
to the ATP/ASP. 

Line 22 Lists the attributes of each convoy the supply unit 
owns . 

Line 23 Lists the attributes of all supply vehicles in the 
unit . 

Lines 26-29 Mark a loop over all resupply vehicles, listing 
the attributes of all supply cargo carried. 

K. "ROUTINE FILE. UP. DATE" 

This routine is called from event UP. S4. AMMO. It is 

used to update the S-4's out standing request list by filing 
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new requests by priority and eliminating duplicate older 
requests of lesser priority. 

AR GUM ENT 

A - Points to supply officer updating. 

COM. Points to company currently updating. 

GLOBAL VARIAB LE (INTEGER) 

SCODE (SUPPLY CO DE) (2- d) . HOLD'S POINTER FOR SCL.V. ITEMS. 

PERMANENT ATT RIBUT E ( IN TEG ER) 

N. SWANT. LIST (NUMBER IN SUPPLY WANT). 

RECURSIVE VARIABLE (IN TEGE R) 

NEW. REQ (NEW REQUISITION). 

OLD . REQ (OLD REQUISITION). 

ROUTINES CALLED 
FILE. UPDATE 

SETS USED 

CWANT. LIST (COMPANY WANT LIST). 

SWANT. LIST (SUPPLY WANT LIST). 

TEMPO RARY_ATTRI3(JTES_1INTEGERL 
DEMAND, for SCL.V. ITEM. 

M.C.CGO. LIST (MEMBER CONVOY CARGO LIST). System generated 

variable indicating whether or not a resupply request is 
on a convoy cargo list. 
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RAC (RESUPPLY AMMUNITION CODE). Attribute of an S CL . V . ITEM 
which points to a specific ammo type carried by the 
supply unit. 

REQUESTOR. Attribute of a RES. REQ pointing to the requesting 
unit . 

RQTY (RESUPPLY QUANTITY). Attribute of a RES. REQ holding the 

/ 

total quantity requested by a unit. 

SPR IORITY (SUPPLY PRIORITY). Attribute of a RES. REQ 

specifying the urgency of need for the ammo request. 

TEMPORA RY ATT RIBUTE ( ALP HA) 

RNOMEN (RESUPPLY NOMENCLATURE). Attribute of a RES. REQ 
specifying the reguested ammo's nomenclature. 

TEMPORAR Y E NTITY 

RES. REQ (RESUPPLY REQUEST). 

SCL. 7. ITEM (SUPPLY CLASS V ITEM). Holds information for a 
supply unit about a particular ammo type used by the 
unit. Belongs to the set S.AMMO. 

PE RMA NE NT ATT RIBUTE (DOUBLE) 

TIME. V . Simulation time. 

PROG RA M LISTI NG 

1 ROUTINE FILE. UPDATE (A, COM) 

2 DEFINE A, COM, OLD. REQ, NEW. REQ AS INTEGER VARIABLES 

3 " FILE THE REQUEST CURRENTLY BEING RECEIVED 

4 " AND CAPTURE DEMAND DATA 

5 PRINT 1 LINE WITH TI ME . V THUS 

ROUTINE FILE. UPDATE CALLED AT TIME.V = :*$.**** 

6 FOR ALL NEW. REQ IN CWA NT .LIST (COM) 

7 WITH M. C.CGO. LIST (NEW. REQ) =0, DO 
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8 

9 

10 
1 1 
12 
13 
1 4 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 
29 
31 


IF NEW.REQ IS NOT IN SOME SWA NT. LIST 
LET DEMAND (SCODE (A, RAC (NEW. SEQ) ) ) = 
DEMAND(SCODE(A,HAC(NEw.REQ) )) + RQTY (NEW.REQ) 
ALWAYS 

FOR ALL OLD. REQ IN S WANT . LIST (A) 

WITH RNOMEN (OLD. REQ) = RNOME N ( NEW . REQ) 

AND M.C.CGO.LIST (OLD. REQ) = 0 

AND REQUESTOR (OLD. REQ) = REQUESTOR (NEW . REQ) , DO 
IF SPRIORITY (OLD. REQ) NE SPRIORITY (NEW. REQ) , 
LET DEMAND jSCODE (A, RAC (NEW.REQ) ) ) = 

DEMAND (S CO DE(A, RAC (OLD. REQ) ) ) 

+ RQTY (NEW. HEQ) - RQTY (OLD . REQ) 

REMOVE OLD. REQ FROM SW ANT . LIST (A) 

REMOVE OLD. REQ FROM CW ANT . LIST (COM) 

DESTROY RES. REQ CALLED OLD. REQ 
ALWAYS 
LOOP 

IF NEW.REQ IS NOT IN SOME SWANT.LIST, 

FILE NEW.REQ IN SWANT.LIST (A) 

ALWAYS 

LOOP 

RETURN 

END 

EXPLANATION OF CODE 


Line 2 


Defines the recursive variables used in the routine. 


L_n e 5 


Prints a message marking the beginning of the event. 


Lines 6- 


•7 Begin the major outer loop for the routine by 



looping over all outstanding requests that have not been 
loaded on a resupply truck. Loop ends on line 28. 

Lines 8-11 Determine if the request has been filed 

previously with the S-4. If not it is treated as new and 
its full demand data is captured. 

Lines 12-25 Begin an inner loop which determines if a 

similar request for the type of ammo in the outer loop 
has been filed previously with the S-4. If so, a 
comparison is made between request priority values. If 
the values are the same, this indicates that the new 
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request has been filed previously and no further action 
is necessary. If the priorities are different, this 
indicates that the unit is increasing its urgency of 
need for the ammo. The new request is filed and the old 
one is destroyed. The difference between the new and 
old values is added to the demand. Loop ends on line 
24 . 

Line 24 Closes the inner loop for the routine. Control is 
transferred back to line 12 to continue comparing 
requests or out to the next new request. 

Lines 25-27 File all genuinely new requests in the S-4's 
Want list. 

Line 29 Closes the main routine loop begun on line 8. 

Control is transferred back to the next request or out. 

L. "ROUTINE LOAD. THE. TRUCKS" 

This routine is called from event UP. S4. AMMO. It is 
used to load supply cargo onto individual trucks. In 
execution, the event checks the number of trucks allocated 
to carry a specific supply request and loads the number of 
trucks specified subject to the weight and cube limitations 
of the truck. 

AR GUMENT (INT E GER) 

A - Pointer value to the S-4 officer. 
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CON . ID (CONVOY ID). Holds the pointer value of the convoy 
currently being filled. 

N.RNDS (NUMBER OF ROUNDS). 

RR (RESUPPLY REQUEST). Holds the pointer of the resupply 
request being currently filled. 

ARGUMENT (REAL) 

CU . REQ (CUBE REQUIRED). Holds the total cube that is required 
in order to ship a resupply request. 

WT. REQ (WEIGHT REQUIRED). Holds the total weight that is 
required in order to ship a resupply request. 

GL OBA L V ARIAB LE (INT EGER) 

RES. REQ (RESUPPLY REQUEST). 

SCODE (SUPPLY CODE) . 

TANK 

RE CUR SIVE VARIABLES (INTEGER) 

RC. TEMP (ROUND/CUBE TEMPORARY). Holds the computational value 
of the number of rounds that may be loaded on a truck 
due to cube restrictions. 

RNDS (ROUNDS) . Holds the number of rounds being released to 
fill a request. 

RW. TEMP (ROUND/WEIGHT TEMPORARY). Holds the computational 
value of the number of rounds that may be loaded on a 
truck due to weignt restrictions. 
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T. COUNT (TRUCK COUNT). Holds the value of the cumber of 

trucks already loaded for a particular resupply request. 

RECURSIVE VARIABLE JR 2AM. 

PCT (PERCENT) . 

R OUTI NES 

LOAD. THE. TRUCK, MIN. F , TRUNC.F 

SETS USED 

CARGO. Contains a listing of the T.CGO loaded on a 
particular truck. 

ELEMENTS. Set of trucks owned by a CONVOY. 

S. UNIT (SUPPLY UNIT). Contains the unit's supply 
vehicles (TANKS) . 

TE MPO RARY ATTRIBUTES (ALPHA) 

RNOMEN (RESUPPLY NOMENCLATURE). Attribute of an SCL.V.ITEM 
containing the name of the particular ammo type. 

TNOMEN (TRUCK NOMENCLATURE). Contains the name of a 
particular ammo type. 

TEMPORA RY AT TRIBUTES (INTEGER) 

FKILL (FIREPOWER KILL). 

KKILL (CATASTROPHIC KILL). 

M. ELEMENTS. Specifies membership in a CONVOY. 

MFKILL (MOBILITY AND FIREPOWER KILL). 

MKILL (MOBILITY KILL). 
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N. CARGO (NUMBER IN CARGO). Indicates the tonal number of 
T.CGO items loaded on a particular truck. 

N. ELEMENTS (NUMBER OF ELEMENTS). In a convoy. 

N.T. ALLOC (NUMBER OF TRUCKS ALLOCATED). Contains the number 
of trucks to be allocated to move the rounds released 
for a resupply reguest. 

ONHAND. Holds the on-hand balance for rounds of a particular 
type at the resupply point. 

POINTER. Of a TANK. 

RAC (RESUPPLY AMMUNITION CODE). Attribute of an SCL.V.ITEM 
which points to a specific ammo type carried by the 
supply unit. 

RDS.PKG (ROUNDS PACKAGE). Attribute of a SCL.V.ITEM 

specifying the number of rounds on an ammo pallet. 

RFILL (RESUPPLY FILL). Attribute of a RES.REQ specifying tne 
amount of ammunition released to fill a reguest. 

RQTY (RESUPPLY QUANTITY). Attribute of a RES.REQ holding the 
total quantity requested by a unir. 

RRPNTR (RESUPPLY REQUEST POINTER). 

SPACE. Attribute of a CONVOY holding the amount of loading 
space available on trucks in the convoy. 
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TCU (TRUCK CUBE) . Tha cube that a trade has available to be 



filled. 



TPNTR (TRUCK POINTER). 



TQTY (TRUCK QUANTITY). Holds the number of rounds within a 



T. CGO that are loaded on a truck. 



TRAC (TRUCK AMMUNITION CODE). Of a T.CGO item. 



TWT (TRUCK WEIGHT). The weight that a truck has available to 



be filled. 



TEMPOR ARY ATTRIBUTES (REAL) 



CU . PK5 (CUB E PACKAGE) Attribute of a SCL.V. ITEM specifying 



the cube of an ammunition pallet. 



WT.PKG (WEIGHT PACKAGE). Attribute of a SCL.V. ITEM specifying 



the weight of a pallet of the ammo being considered. 



TEMPORARY ENTITY 



T.CGO. Supplies carried on a resupply vehicle (TANK) . 



PROGRAM LISTING 



1 ROUTINE LOAD. THE. TRUCKS 

2 (A ,RR , WT. REQ, CU. REQ/ N. RNDS, CON. ID) 

3 DEFINE A,RR,N.RNDS,CON.IB,T.COUNT,RW. TEMP , 

4 RC. TEMP , RNDS AS INTEGER VARIABLES 

5 DEFINE WT. REQ,CU.REQ,PCT AS REAL VARIABLES 

6 PRINT 1 LINE THUS 

ROUTINE LOAD THE TRUCKS CALLED 

7 LET T. COUNT = 0 

8 FOR EVERY TANK IN S. UNIT (A) 

9 WITH M. ELEMENTS (TANK) EQ 0 

10 AND MKILL (TANK) EQ 0 AND FKILL (TANK) EQ 0 

11 AND MFKILL (TANK) EQ 0 AND KKILL (TANK) EQ 0, DO 

12 "LOO? CHECK 

13 LET T. COUNT = T. COUNT +1 

14 IF T. COUNT GT N . T. ALLOC (RES . RE Q) OR WT . REQ LE 0 

15 OR CU . REQ LE 0 OR N . RNDS LE 0 

16 LEAVE 

17 OTHERWISE 

18 " CHECK IF ITEMS EXCEED THE TRUCK’S CAPACITY 

19 " IF SO, ADJUST 
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20 

21 

22 

23 

24 

25 

26 
27 
23 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 
4 1 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 

56 

57 

58 

59 

60 
6 1 
62 

63 

64 



IF WT 
LET 



LET RC.TEMP = 



REQ GT TWT (TANK) OR CU.REQ GT TC U (TANK) 
RW.TEMP = TWT (TANK) 

/WT. P KG {SCODE ( A, RAC (RES. REQ) ) ) 

* RDS.PKG (SCODE (A, RAC (RES. REQ) ) ) 
TC U (TANK) 

/CU.PKG(5C0DE (A,RAC(RES.REQ) )) 

* RDS.PKG (SCODE(A,HAC(RES. REQ) ) ) 
RNDS = MIN. F (RW. TEMP, RC. TEMP) 

N. RNDS = N.RNDS - RNDS 



LET 
LET 
ELSE 

LET RNDS = N.RNDS 
LET SPACE (CON. ID) = 1 
ALWAYS 
CREATE A T.CGO 

LET TPNTR (T.CGO) = POINTER (TANK) 

LET RRPNTR (T.CGO) = RES. REQ 

LET TNOKEN (T.CGO) = RNOMEN (RES .REQ) 

LET TRAC (T.CGO) = RAC (RES. REQ) 

LET TQTYjT.CGO) = RNDS 
FILE T.CGO IN CARGO (TANK) 



ON THE RES. REQ 



- RNDS 
RES. REQ 



"REDUCE THE OUTSTANDING QUANTITY 
LET N.RNDS = N.RNDS - RNDS 
LET RFILL (RES. REQ) = RFILL (RES . REQ) + RNDS 
LET RQTY (RES . REQ) = RQTY (RES . R EQ) - RNDS 
"REDUCE THE ON-HAND BALANCE OF SUPPLY STOCKS 
LET ONHAND(SCODE (A, RAC (RES. REQ)) ) = 

ONHAND (ScODE (A, RAC (RES. REQ) ) ) 
"REDUCE THE WEIGHT AND CUBE REQ* D FOR THE 
LET WT. REQ= TRUNC. F ( WT .REQ - RNDS 

* WT.PKG (SCODE (A, RAC (RES. REQ) ) ) 
/RDS.PKG (SCODE (A , R AC (RES. REQ) ) ) 
TRUNC. F(CU. REQ - RNDS 

* CU.PKG (SCODE (A, RAC (RES. REQ) ) ) 
/RDS.PKG (SCODE (A , R ACjRES . REQjJ j) 

"REDUCE THE WEIGHT AND CUBE AVAIL ON THE T" 
LET T WT (TAN K) = TRUNC. F (TWT (TANK) - RNDS 

* WT.PKG (SCODE (A, RAC (RES. REQ) ) ) 
/RDS.PKG (SCODE (A , RAC (RES. REQ ) 

LET TCU(TANK) = TRUNC. F(TCU (TANK) - RNDS 

* WT.PKG (SCODE (A, RAC (RES. REQj j j 



LET CU. REQ= 



) 



RUCK 



FILE 

LOOP 

RETURN 

END 



/RDS.PKG (SCODE (A , RAC (RES. REQ 
TANK IN ELEMENTS (CON. ID) 



EXPLANATION OF CODE 



Lines 3-5 Define recursive variables used in the routine. 



Line 6 Prints a message indicating that the routine has 
been called. 

Lines 8-11 Begin the major loop for the routine to assign 
the resupply mission to vehicles in the supply unit that 
have not previously sustained damage or been assigned to 
a convoy. Loop ends on line 62. 
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Lines 12-17 Check the loop for completion through the 

assignment of all trucks allocated to the mission, or 
through the completion of the loading process. 

Lines 18-32 Check if the request exceeds the carrying 

capacity of the truck being loaded. If so, the amount 
being loaded is adjusted to the maximum load for that 
truck. 



Line 33 Creates a TRUCK. CARGO to hold information as to the 
type and quantity of ammo to be loaded on a truck. 

Line 34 Captures the pointer value of the truck the cargo 
is leaded on. 

Line 35 Captures the pointer value of the resupply request 
being filled. 

Line 36 Captures the nomenclature of the request being 
filled. 

Line 37 Captures the ammunition code of the request being 
filled 



Line 38 Captures the quantity being loaded on the truck. 
Line 39 Files the cargo on the last truck in the convoy. 
Line 41 Reduces the number of rounds yet to be filled for 
the request 
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Line 42 Adds the quantity released to the fill attribute of 
the request. 

Line 43 Reduces the required quantity for the resupply 
request. 

Lines 44-46 Reduce the on-hand stocks for the ammo type at 
the supply point. 

Lines 47-53 Reduce the weight and cube required to fill the 
request. 

Lines 54-60 Reduce the weight and cube available on the 
truck to fill requests. 

Line 61 Files the truck in the active convoy. 

Line 62 Closes the major routine loop begun on line 8. 

Control is either transferred back to fill another truck 
with the same cargo or transferred out. 

M. "ROUTINE WT.AND.CU" 

This routine is called by event UP. S4. AMMO and is used 
to compute the total weight and cube capacity present at 
battalion which can be used to carry supplies. 

ARGUMEN T (I NTEGER) 

A - Points to supply officer updating. 

ARGUMEN T ( REAL) 
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CU (CUBE) . Holds the maximum cube that may be loaded on a 
resupply vehicle. 

CU. AVAIL (CUBE AVAILABLE). Holds the total cube capacity that 
is available within the supply unit for the shipment of 
supplies. 

TRKS. AVAIL (TRUCKS. AVAILABLE) . Holds the total number of 

trucks available for assignment to a resupply mission at 
any time. 

WT (HEIGHT) . Holds the maximum weight that may be loaded on a 
resupply vehicle. 

WT. AVAIL (WEIGHT AVAILABLE). Holds the total weight capacity 
that is available within the supply unit for the 
shipment of supplies. 

GL OBA L VARIAB LE (INTEGER) 

TANK 

S. UNIT (SUPPLY UNIT). Contains the unit's supply 
vehicles (TANKS) . 

TE MPO RARY ATTRIB UTE S I INTEGER), 

FKILL (FIREPOWER KILL). 

KKILL (CATASTROPHIC KILL). 

M. ELEMENTS. Specifies membership in a CONVOY. 

MAX. CU3E (MAXIMUM CUBE). 
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MAX. WT (MAXIMUM HEIGHT) 



MFKILL (MOBILITY AND FIREPOWER KILL). 



MILL (MOBILITY KILL). 



WT (WEIGHT) . Holds the maximum weight that may be loaded on a 



resupply vehicle. 



ROU TIN E CALLED 



WT. AND. CUBE 



PR OGRAM LISTI NG 



1 ROUTINE WT. AND. CUBE GIVEN A 

2 YIELDING WT. AVAIL ,CU. AVAIL ,TRKS . AVAIL, WT ,CU 

3 DEFINE WT. AVAIL, CU. AVAIL, WT,CU AS REAL VARIABLES 

4 DEFINE TRKS. AVAIL, A AS INTEGER VARIABLES 

5 PRINT 1 LINE THUS 

ROUTINE WT. AND. CUBE CALLED 

6 ' • 

7 •* DETERMINE THE WT. AND CU3E AVAIL FOR SHIPPING 

8 FOR EVERY TANK IN S. UNIT (A) 

9 WITH M. ELEMENTS (TANK) EQ 0 

10 AND MKILL (TANK) EQ 0 AND FKILL (TANK) EQ 0 

11 AND MFKILL (TANK) EQ 0 AND KKILL (TANK) EQ 0, DO 

12 LET WT. AVAIL = WT. AVAIL + MAX. WT(TANK) 

13 LET CU. AVAIL = CU. AVAIL + MAX . CUBE (TANK) 

14 LET TRKS. AVAIL = TRKS. AVAIL + 1 

15 LET WT = MAX. WT (TANK) 

16 LET CU = MAX. CUBE (TANK) 

17 LOOP 

18 RETURN 

19 END 

EXPLANA TION O F CODE 



Lines 3-4 Define recursive variables used in the routine. 



Line 5 Prints a message indicating that the routine has 



been called. 



Lines 8-17 Begin the major loop for the routine, looping 



over all available cargo carriers, summing the total 



weight and cube available for shipment, determining a 
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total number of trucks available, and determining the 
max weight and max cube available on any one truck. 

N. "ROUTINE PRI. RESUPPLY" 

This routine is called by event UP. S4. AMMO and is used 
to determine an optimum fill for priority 1 and 2 
requisitions. In execution, the routine seeks to fill all 
priority 2 requisitions to a minimum percentage of fill for 
all requests by: first, setting multipliers to reduce 
priority 2 fill; second, re-evaluating the overall fill of 
priority 2 requests; and third, if necessary, reducing fill 
on priority 1 requests to open more space for priority 2 
requests . 

AR GUM ENT (INTEGER) 

A - Points to the S-4 currently updating. 

LON 1 . Variable which indicates whether Level of Need 1 

requests are currently filed with the supply officer. 
L0N2. Variable which indicates whether Level of Need 2 

requests are currently filed with the supply officer. 
A RGUM ENT (REA L) 

CU. AVAIL (CUBE AVAILABLE). Holds the total cube capacity that 
is available within the supply unit for the shipment of 
supplies. 
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MOL 1 (MULTIPLIER 1) . Helds the multiplier for LON 1 requests 
which is used to reduce the fill on such requests. 

MUL2 (MULTIPLIER 2). Holds the multiplier for LON 2 requests 
which is used to reduce the fill on such requests. 

WT. AVAIL (WEIGHT AVAILABLE). Holds the total weight capacity 
that is available within the supply unit for the 
shipment of supplies. 

GL OBAL VARIA BLES (INTEGER) 

RES. REQ (RESUPPLY REQUEST). 

SCODE (SUPPLY CODE) . 

GLOBAL VARIAB LES (REAL) 

C.L1PCT (CRITICAL L0N1 PERCENTAGE). Holds the maximum 

percentage that L0N1 requisitions may be reduced to in 
order to release space on a convoy for other critical 
L0N1 and LON2 requests. 

C. L2CU (CRITICAL LON2 CUBE). Holds the maximum percent of 
cube that L0N2 requisitions may be cut to in order to 
release space on a convoy for other critical LON 1 and 
L0N2 requisitions. 

C.L2WT (CRITICAL L0N2 WEIGHT). Holds the maximum percent of 
weight that LON2 requisitions may be cut to in order to 
release space on a convoy for other critical L0N1 and 
L0N2 requisitions. 
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RE CUR SIVE VARIABLE (SEAL) 

CU. SHIP (CUBE OF SHIPMENT). Combined total cube of current 
LON1 and LON2 requests. 

Cl. Holds the total cube of current L0N1 requests. 

C1PCT. Percent of L0N1 requests which can be filled if all 
L0N2 requests are filled to a minimum based on cube. 

C2. Holds the total cube of current L0N2 requests. 

C2PCT. Percent of L0N2 requests which can be filled if all 
LON 1 requests are filled based on cube. 

WT. SHIP (WEIGHT OF SHIPMENT). Combined total weight of 
current LON 1 and L0N2 requests. 

W1 . Holds the total weight of current LON1 requests. 

W1PCT . Percent of L0N1 requests which can be filled if all 
L0N2 requests are filled to a minimum based on weight. 

W2. Holds the total weight of current L0N2 requests. 

W2PCT. Percent of L0N2 requests which can be filled if all 
L0N1 requests are filled based on weight. 

ROUTI NES 

MAX. F, MIN.F, PRI. RESUPPLY 
SET 

SWANT. LIST (SUPPLY WANT LIST). 

-TEMPORA RY ATT RIBUTE 1 INTEGER), 
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RAC (R2SUPPLY AMMUNITION CODE). Attribute of an SCL.7. ITEM 
which points to a specific ammo type carried by the 
supply unit. 

RDS.PKG (ROUNDS PACKAGE). Attribute of a SCL.V.ITEM 

specifying the number of rounds on an ammo pallet. 

RQTY (RESUPPLY QUANTITY). Attribute of a RES.2EQ holding the 
total quantity requested by a unit. 

SPRIORITY (SUPPLY PRIORITY). Attribute of a RES.REQ 

specifying the urgency of need for the ammo request. 

TE MPOR A RY ATT RIB UTE (REAL) 



CU. PKG (COB E PACKAGE). Attribute of a SCL.V.ITEM specifying 
the cube of an ammunition pallet. 



WT. PKG (WEIGHT PACKAGE). Attribute of a SCL.V.ITEM specifying 



the 



1 

2 

3 

4 

5 

6 

7 

8 
9 

10 
1 1 
12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 



weight of an ammunition pallet. 



PR O GR AM LI STI NG 



ROUTINE PRI. RESUPPLY GIVEN WT. AVAIL, CU. AVAIL , A 

YIELDING MUL1,MUL2,LON1 , LON2 
DEFINE A,LON1 ,LON2 AS INTEGER VARIABLES 
DEFINE W1,W2,C1,C2,WT. SHIP , CU . S HI? , M UL 1 , MUL2 , 

WT . A VAIL , CU . A VAIL, W2PCT, C2 PCT , W 1 PCT , C 1PCT 
AS REAL VARIABLES 
PRINT 1 LINE THUS 
ROUTINE PRI. RESUPPLY CALLED 
" DETERMINE WEIGHT AND CUBE REQUIRED 
•• FOR LON 1 & LON2 MISSIONS 
FOR EVERY RES.REQ IN S WANT . LIS T ( A) 

WITH SPRIORITY (RES.REQ) =1 
OR SPRIORITY (RES.REQ) = 2. DO 

GO TO L1,L2 PER SPRIORITY (RES . REQ) 

'Ll' LET W1 = W1 + HT.PKGjSCODE (A, RAC(EES. REQ) ) ) 
*RQTY (RES.REQ) 

/RDS.PKG (SCODE (A, RAC 
LET Cl = Cl + CU. PKG (SCODE (A, RAC (R 
*RQTY (RES.REQ) 

/RDS.PKG (SCODE (A, RAC (RES.REQ) ) ) 

LET LON 1 = 1 
CYCLE 

* L2 ' LET W2 = W2 + WT . PKG (SCODE (A , RAC (RES. REQ) ) ) 
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23 *RQTY (RES.REQ) 

24 /RDS.PKG (SCODE (A. RAC (RES.REQ) ) ) 

25 LET C2 = C2 + WT . PKG (SCODE (A . R AC (RES . REQ) )\ 

26 *RQTY(RES.REQ) /RDS.PKG (SCODE (A , RAC (RES.REQ) ) ) 

27 LET LON2 = 1 

28 LOOP 

29 LET WT. SHIP = WT.SHIP + Wl + W2 

30 LET CU .SHIP = CU.SHIP + C2 + C2 

31 * » 

32 '’DETER IF THE MIN % OF LON 2 ITEMS ARE SHIPPED. 

33 IF (WT.SHIP GT WT. AVAIL OR CU.SHIP GT CU. AVAIL) 

34 AND LON2 EQ 1 

35 LET W2PCT = (WT. AVAIL- Wl) /W2 

36 LET C2PCT = (CU. AV AIL-Cl[/C2 

37 "REDUCE THE FILL ON L0N2 REQUIREMENTS 

38 LET MUL2 = (MIN. F (W2PCT, C2PCT, 1.0) ) 

39 LET MUL 1 = 1.0 

40 • ' 

41 "REDUCE LON1 FILL TO ALLOW MORE SPACE 

42 IF W2PCT LT C.L2WT OR C2PCT LT C.L2CU 

43 AND LON1 EQ 1 

44 LET W 1 PCT = (WT. AVAIL-W2*C. L2WT) /Wl 

45 LET Cl PCT = (CU. AV AIL-C2*C. L2CU) /Cl 

46 LET MUL 1 = (MAX. F ( W 1PCT , C 1 PC T ,C . LI PCT) ) 

47 LET MUL2 = (MIN.F(C.L2WT,C.L2CU, 1 .0) ) 

48 ALWAYS 

49 ALWAYS 

50 RETURN 

51 END 

EXPLANATION OF CODS 



Line 3-6 Define recursive variables used in the routine. 



Line 7 Prints a message narking the beginning of the 
routine. 

Lines 10-12 Begin the major loop of the routine looping 
over all resupply requests in the S-4's want list and 
identify the priority 1 and 2 requests. Loop ends on 
line 28. 

Line 13 Transfers control based on the priority of the 
request. 

Lines 14-16 Sum the total weight of all priority 1 
requests. 



Lines 17-19 Sum the total cube of all priority 1 requests 



Line 20 Indicates the presence of an L0N1 request. 

Line 21 Cycles to next request. 

Lines 22-24 sum the total weight of all priority 2 
requests. 

Lines 25-26 Sum the total cube of all priority 2 requests. 

Line 27 Indicates the presence of an LON2 request. 

Line 28 Ends the major loop begun on line 10. Transfer of 
control is either to the next request or out. 

Lines 29-30 Calculate the total weight and cube of 

outstanding requests due to priority 1 and 2 requests. 

Lines 32-39 Determine if all priority 2 requests have been 
filled. If not, it establishes a multiplier, Hul2, to 
reduce fill on priority 2 reguests in order to open up 
space on trucks to fill a greater number of LON2 
requests. The IP check ends on line 49. 

Lines 41-48 Check again to see if all LON2 requests have at 
least been partially filled. If not, it establishes a 
multiplier, MUL1, to reduce the fill of priority 1 
requests to open up space on trucks until the priority 2 
requests have been filled. Priority 1 requests will be 
reduced only to the percentage necessary to fill 
priority 2 requests, or to a user designated critical 
priority of fill whichever comes first. 
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0 . 



"EVENT BAT. L. TIME" 



Event BAT. L. TIME is initially scheduled in the main 
program and subsequently reschedules itself each day of the 
simulation. The event is used to start and end a battle and 
to schedule moves. 

EVENT SC HEDUL ED 

MOVE 

GLOBAL V ARI ABLES (INTEGER) 

CNUM (COMPANY NOMBER). Specifies the number of 
COMPANY. COMMANDERS created. 

RSTREAM (RESUPPLY RANDOM NUMBER STREAM) . 

WSTREAM (WEAPON RANDOM NUMBER STREAM). 

GLOBAL VARIABL ES (REAL) 

3. END (BATTLE END). Termination time of daily battle. 

B. START (BATTLE START) . Start time of daily battle. 

PE RMA N ENT ATT R IB UTSS _ 1 R E AL 

TIME. V 

TE MPORARY A TTRIBUTE (INTEGER) 

MARCH. ORDER. Argument for the event move holding the pointer 
of the company receiving orders to move. 

RE CUR SIV E VA RIABLES (INTEGER) 

I - Loop index. 

R OUTI NE S CA LLED 
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RANDOM. F, TRUNC. F, and UNIFORM. F 





PROGRAM LISTING 


1 

2 

3 

4 


EVENT BAT. L. TIME 

i i 

DEFINE I AS AN INTEGER VARIABLE 
PRINT 1 LINE WITH TIME.V THUS 

EVENT BAT. L. TIME CALLED AT TIME.V = 


5 

6 


» i 

LET B. START = TRUNC. F (TIME. V) 
+UNIFORM.F (0.0, 1.00, WSTREAM) 


7 

8 
9 

10 
1 1 
12 

13 

14 

15 

16 


LET B . END = 3. START +.25 

IF B.END LT TRUNC. F (TIME.V) + 1.0, 

RESCHEDULE A BAT. L. TIME AT TRU NC. F (TIME . V) + 1 . 0 
ELSE 

RESCHEDULE A BAT. L. TIME AT B.END 
AT WAYS 

FOR I = 1 TO CNUM, DO 

IF RANDOM. F (RSTREAM) LT .8, 

SCHEDULE A MOVE (I) AT B.END + .1 
PRINT 3 LINES WITH I THUS 

i i i t t t i i « t i i i > t i i i i t i t i i i i t 

MOVE SCHEDULED FOR COMPANY * 

i t t i i i t i « t t t i i i t i t i t « i i t i i i 


17 

18 

19 

20 


ALWAYS 

LOOP 

RETURN 

END 

EXPLANATION OF CODE 


Line 3 


Defines the recursive variable used in the routine. 


Line 4 


Prints a message marking the start of the routine. 


Line 6 


Randomly picks a battle start time over the 24 hour 



period . 

Line 7 schedules a battle stop time 6 hours later. 

Lines 8-12 Reschedule the battle for the next day. 

Lines 13-18 Randomly select a company to move at the end of 
a day's battle(event MOVE). Print a message identifying 
the unit. 
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P. "EVENT MOVE" 

Event MOVE is scheduled in event BAT. L. TIME. The event 
only takes place after a battle and is used solely to 
schedule and exercise rhe redistribution logic. 

ARGUMENTS 

MARCH. ORDER. Argument for event MOVE holding the pointer of 
the company receiving orders to move. 

GL OBA L VAR IABLE (INTEG ER) 

PLATOON. LEADER 
SET 

CO. UNIT (COMPANY UNIT). 

TE MPO RAR Y ATT RI BUTE S (INTEGER) 

C - Holds the value of the company currently moving. 

DISTR (DISTRIBUTOR) . Argument for event REDISTRIBUTE holding 
the value of the unit's PLATOON. LEADER. 

EVENT SC HEDUL ED 
REDISTRIBUTE 

PR OGRA M LIS TI N G 

1 UPON MOVE (C) 

2 NORMALLY MODE IS INTEGER 

3 FOR EVERY PLATOON . LEADER IN PLAT. UNIT (C) , DO 

4 SCHEDULE A REDISTRIBUTE (PLATOON. LEADER) NOW 

5 LOOP 

6 RETURN 

7 END 

E XPL ANATION OF CODE 
Line 2 Defines the mode as integer. 
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Lines 3-5 Schedule a move for each platoon in the company. 

Q. "EVENT CO. RESUPPLY. ARE" 

Event CO. RESUPPLY . ARR is scheduled from event 
UP. S4. AMMO. The event distributes the ammunition assets 
received by a company to subordinate platoons according to 
their most recent LON. It then sends the RSV/convoy bacJc to 
the battalion trains after an appropriate time delay 
simulating a delivery from the ATP/ASP. 

ARGUMENT 

CNVY (CONVOY) . Argument Of CO .RESUPPLY. ARR (CO MPANY RESUPPLY 
ARRIVE) carrying the pointer of the convey arriving. 

CO. CNVY (COMPANY CONVOY). Argument of the event 

CO. RESUPPLY. ARR (COMPANY RESUPPLY ARRIVE) holding the 
pointer value for the convoy arriving in the area. 

DEFINE TO MEAN 

AMMO 1 . AP. TOW (A RMOR PIERCING/TOW ROUNDS). 

AMM02 . HE. DRAG (HEAT/DRAGON ROUNDS). 

AMM03. AW1 .OR .MSL3 (ALTERNATE WEAPON 1 OR MISSILE 3). 

AMM04 . AW2. OR. ADM (ALTERNATE WEAPON 2 OR AIR DEFENSE 
MISSILE) . 

EVENTS S CHEDU LED 
3N. ARRIVE (BA TT A LION ARRIVE). 

GL OBA L VA RIAB LES (INTEGER) 
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PC0D2 (PLATOON CODE) (2-d) . Holds the pointer value for a 
platoon's PCL. V. ITEMS (PLATOON CLASS V ITEMS). 

PLATOON. LEADER 

RES. REQ (RESUPPLY REQUEST). 

TANK 

TSTREAM (TRIP RANDOM NUMBER STREAM). 

GLO BAL VARIABL ES (REAL) 

CCODE (COMPANY AMMUNITION CODE). 

MAXTRIP (MAX TRIP). The maximum time required for a convoy to 
reach its intended destination. 

MINTRI P (MIN TRIP). The minimum rime required for a convoy to 
reach its intended destination. 

PE RMANENT ATT RIB UTE5 (REAL) 

TIME. V 

REC URSIVE VARIABLES (IN TEG ER) 

ASSETS. Holds the amount of ammo left to be issued. 

DEL. Holds the amount of ammo initially delivered. 

NO. BATTLE. Indicates whether RES. REQs should be filled. 

"0" indicates no 
"1" indicates yes 

TEMP. Place holder for release point of the convoy. 

ROUTI NE S CALL ED 

COM. AMMO, INT.F, P. CLASS. V 
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SE TS USED 

C.CGO. LIST (CONVOY CARGO LIST). 

CO. UNIT (COMPANY UNIT) . 

CWANT. LIST (COMPANY WANT LIST). 

PLAT. UNIT (PLATOON UNIT). 

SREQN. LIST (SUPPLY REQUISITION LIST). 

SWANT. LIST (SUPPLY WANT LIST). 

TNK. ALIVE (TANK ALIVE) . 

TEMPORARY ATTRIBUTES (I NTE GER) 

AMM05 (AMMUNITION 5). Of TANK. 

AMM06 (AMMUNITION 6). Of TANK. 

AP. TOW (ARMOR-PIERCING/TOW) . Ammunition 1 OF TANK. 

TAC1 . (TANK AMMUNITION CODE 1). 

TAC2. (TANK AMMUNITION CODE 2). 

TAC3. (TANK AMMUNITION CODE 3) . 

TAC4. (TANK AMMUNITION CODE 4). 

TAC5. (TANK AMMUNITION CODE 5). 

TAC6 . (TANK AMMUNITION CODE 6). 

AW 1 . OR . MSL 3 (ALTERNATE WEAPON 1 OR MISSILE 3). Ammunition 3. 
AW2. OR. ADM (ALTERNATE WEAPON 2 OR AIR DEFENSE MISSILE). 
Ammunition 4. 

C. MV. STATE (CONVOY MOVEMENT STATE). 
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C. SHORT (COMPANY SHORT AGS) . Total rounds short for a type 



ammo • 



COCDR (COMPANY COMMANDER). Of TANK. 

FKILL (FIREPOWER KILL) . 

FLAG Yielding argument of W.AMMO and COM. AMMO, not used in 
this routine. 



HE. DRAG (HEAT/DRAGON ROUNDS). Ammunition 2 of TANK. 

KKILL (CATASTROPHIC KILL). 

MKILL (MOBILITY KILL). 

0H1 (ON-HAND 1). Current balance of ammunition 1 on a TANK. 

OH2 (ON-HAND 2). Current balance of ammunition 2 on a TANK. 

OH3 (ON-HAND 3). Current balance of ammunition 3 on a TANK. 

0H4 (ON-HAND 4). Current balance of ammunition 4 on a TANK. 

OHS (ON-HAND 5). Current balance of ammunition 5 on a TANK. 

0H6 (ON-HAND 6). Current balance of ammunition 6 on a TANK. 

P. SHORT (PLATOON SHORTAGE). Current shortage of a PCL.V.ITEM 
(PLATOON CLASS V ITEM) . Unique to each platoon and ammo 
type. 

PCURR. LOAD (PLATOON CURRENT LOAD). On-hand balance for an 
ammo type. Unique for each platoon and ammo type. 

RAC (RESUPPLY AMMUNITION CODE). 
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RCNVY (RESUPPLY CONVOY). Argument of the event BN. ARRIVE 

(BATTALION ARRIVE) carrying the pointer of the convoy. 
REQUESTOR. Attribute of a RES. REQ (RESUPPLY REQUEST) 
specifying the unit making the request. 

RFILL (RESUPPLY FILL). Attribute Of a RES. REQ (RESUPPLY 

REQUEST) specifying the amount of ammunition released to 
fill a request. 

RP (RELEASE POINT). Attribute of a convoy specifying the 
convoy's destination. 

SL0AD1 (STORED LOAD 1) . Optimal load ammo type 1. 

SLOAD2 (STOWED LOAD 2) . Optimal load ammo type 2. 

SL0AD3 (STOWED LOAD 3) . Optimal load ammo type 3. 

SL0AD4 (STOWED LOAD 4) . Optimal load ammo type 4. 

SLOAD5 (STOWED LOAD 5) . Optimal load ammo type 5. 

SL0AD6 (STOWED LOAD 6) . Optimal load ammo type 6. 

SP (START POINT). Attribute of a convoy specifying the 
convoy’s origin. 

STATUS. Indicates the current location of a convoy. 

SYS. TYPE (SYSTEM TYPE). 

RO UTIN ES CALLED 
UNIFORM. F, UP. DATE, W.AMMO 
PR OGRA M LISTI NG 

1 EVENT CO. RESUPPLY. ARR(CNVY) 

2 DEFINE FLAG, NO. BATTLE, TEMP, CNVY, ASSETS, 
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3 

4 

5 

6 

7 

8 

9 

1 0 

1 1 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 

56 

57 

58 

59 

60 

61 

62 

63 

64 

65 

66 

67 

68 






AND DEL AS INTEGER VARIABLES 
PRINT 2 LINES WITH TIME. V, CNVY 
EVENT CO. RESUPPLY. ARE CALLED 
TIME. V = A#.**** CONVOY = ***** 



HUS 



t • 



' * BRING THE CONVOY OUT OF KYPERSPACE 
LET C. MV. STATE (CNVY) = 0 



REQ) ) ,DO 



i! 



FOR EVERY RES. REQ IN C . CGO . LIST (CNVY) f DO 
LET ASSETS = RFILL (RES . REQ) 

FOR EVERY P L ATOON . LEADER 

IN CO. UNIT (REQUESTOR (RES 
LET DEL= 

INT.F (P. SHORT (PCODE (PLATOON. LEADER, RAC (RES. REQ) 
/C. SHORT (CCODE (REQUESTOR (RES. REQ) ,RAC (RES. REQ) 

* RFILL (RES. REQ) ) 

LET ASSETS = ASSETS - DEL 
LET PCURR.LOAD(PCODE(PLATOON. LEADER, RAC (RES. REQ) ) ) 
PCURR . LOAD (PCODE (P LATOON . LEADE R, RAC (RES. REQ) ) ) +DE 

• • FILL TANKS 

FOR EVERY TANK IN PLAT. UNIT (PLATOON. LEADER) , DO 
IF MKILL (TANK) =1 OR MF KILL (TAN K) = 1 
OR FKILL (TANK) =1 OR KKILL (TANK) =1 
CYCLE 
OTHERWISE 



1 1 



t • 



i « 



• • 



IF TAC1 (TANK) =RAC (RES 
LET OH 1 (TANK) = OH1 (TA 



BE &, 

< (SiOADI (TANK) -OH1 (TANK) ) ) 

F. SHORT (PCODE (PLATOON .LEADER, RAC (RES. REQ) ) ) 



:) + DEL 



/ 



t • <JU UU1 If 1 f UAL VUH • li iill | 

LET AMMO 1 (TANK) =AMM01 (TANK) +DEL 



< (SLOADt (TANK) -AMMOI (TANK) ) ) / 
P. SHORT (PCODE (PLATOON . L EADER , RAC (HES. REQ) ) ) 

GO TO TANKLOOP 
OTHERWISE 

IF TAC2 (TANK) =RAC (RES. REQ) 

LET OH2 (TANK) =OH2 (TANK) +DEL 

< (SLOAD2 (TANK) -OH2 (TANK) )) / 

P. SHORT (PCODE (PLATOON. LEADER, RAC (RES. REQ) ) ) 
LET AM MO 2 (TANK) =AMM02 (TANK) +DEL 

< (SLOAD2 (TANK) -AMM02 (TANK) ) ) / 
P. SHORT (PCODE (PLATOON. LEADE R , RAC (RES. REQ) ) ) 

GO TO TANKLOOP 
OTHERWISE 



IF TAC3 (TANK) =RAC (RES. REQ) 

LET OH3 (TANK) = OH3 (TANK ) + DEL 

< (SLOAD3 (TANK) -0H3 (TANK) ) ) / 
P. SHORT (PCODE (PLATOON . L EAD ER, RAC (RES. REQ) ) ) 
LET AMM03 (TANK) =AMM03 (TANK) +DEL 

i (SL0AD3 (TANK) -AMM03 (TANK) ) ) / 
P. SHORT (PCODE ( PLATOON . LEADER , RAC (RES. REQ) ) ) 
GO TO TANKLOOP 
OTHERWISE 



• i 



IF TAC4 (TANK) =RAC (3ES. REQ) 

LET O H4 (TANK) = OH4 (TANK) + DEL 

< (SLOAD4 (TANK) -OH4 (TANK) ) ) 
P. SHORT (PCODE (PLATOON . LEADER, RAC (RES. REQ) 
LET AMM04 (TANK) =AMM04 (TANK) +DEL 

* (SLOAD4 (TANK) -AMM04 (TANK 
P. SHORT (PCODE (PLATOON . L BADE S , RAC (RES . R 
GO TO TANKLOOP 
OTHERWISE 



/ 

)) 

/ 

) ) 



217 



t- II 



69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 

81 

82 

83 

84 

35 

85 

87 

88 

89 

91 

92 

93 

94 

95 

96 

97 

98 

99 

100 

101 

102 

103 

104 

105 

106 

107 

108 

109 

1 10 

111 

112 

113 

114 

115 

116 

117 

118 

119 

120 

121 

122 

123 

124 

125 

126 

127 

128 



IF TAC5 (TANK) =RAC (RES. REQ) 

LET OH5 (TANK) = OHS (TANK) + DEL 

< (SLOAD5 (TANK) -OH5 jTANK) ) ) / 
P. SHORT {PCODE ( PLATOON . L EADER , RAC (EES. REQ) ) ) 

LET AMM05 (TANK) =AMM05 (TANK) +DEL 

< (SLOAD5 (TANK) -AMM05 (TANK) ) ) / 
P. SHORT (PCODE (PLATOON. L EADER , RAC (RES . REQ) ) ) 
GO TO TANKLOOP 
OTHERWISE 

IF TAC6 (TANK) =RAC (EES. REQ) 

LET OH6 (TANK) = OH6 (TANK) ♦ DEL 

< (SLOAD6 (TANK) -OH6 (TANK) ) ) / 
P. SHORT (PCODE (PLATOON . L EADER , RAC (RES. REQ) ) ) 

LET AMMOo (TANK) = AMM06 (TANK) +DEL 

<SLOAD6 (TANK) -AMM06 (TANK) ) / 
P. SHORT (PCODE (P LATOOK. L EADE R , RAC (RES. REQ) ) ) 
ALWAYS 

' TANKLOOP 1 
LOOP 

1 DP DATE FILES • 

IF RES.REC IS NOT IN SOME SWANT.LIST 
AND RES. REQ IS IN SOME CWANT.LIST, 

REMOVE RES. REQ 

FROM CWANT.LIST (REQUESTOR (RES. REQ) ) 

ALWAYS 

IF RES. REQ IS NOT IN SOME SREQN. LIST 
FILE RES. REQ IN SREQN . LIST (SP (CNVY) ) 

ALWAYS 

LET STATUS {RES. REQ) = "ATP" 

LET DEL = 0 



LOOP 

LOOP 

FOR EVERY TANK IN TNK. ALIVE 
WITH COCDR (TANK) EQ RP (CNVY), DO 
IF SYS. TYPE (TANK) EQ 7, 

CYCLE 
OTHERWISE 
LET NO. BATTLE = 1 

CALL W. AMMO (TANK, NO. BATTLE) YIELDING FLAG 

LOOP 

« « 



FOR EVERY PLATOON . LEADER IN CO . U NIT ( R? (C N VY) ) , DO 
CALL P. CLASS. V (PLATOON. LEADER) 

LOOP 

LET NO. BATTLE = 1 

CALL COM. AMMO (RP (CNVY) , NO. BATTLE) YIELDING FLAG 

'•SEND THE CONVOY HOME 
LET TEMP = RP (CNVY) 

LET RP (CNVY) = SP(CNVY) 

LET SP (CNVY) = TEMP 

LET C. MV. STATS (CNVY) = 1 

SCHEDULE A BN . ARRIVE (CNVY) 

IN UNIFORM. F (MINTRI? ,MAXTRIP ,TSTREAM) MINUTES 
RETURN 
END 



EX PLANATION O F CODS 
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Lines 2-3 Define the recursive variables used in the 
routine. 

Line 4 Prints a message marking the start of the routine. 

Lines 6-7 Change the convoy movement state to zero. 

Line 9 Begins the routine's major loop over all resupply 
requests in the arriving convoys cargo list. Loop ends 
on line 104. 

Line 10 Captures the quantity delivered by the convoy as a 
local variable for computation purposes. 

Lines 12-13 Begin an inner loop over every platoon leader 
in the company in order to distribute the arriving 
supplies. Loop ends on line 103. 

Lines 14-17 Set the delivery for a particular platoon equal 
to [platoon shortage / company shortage] multiplied by 
the deliver quantity. 

Line 18 Subtracts the delivery from the assets available. 

Lines 19-20 Adjust the platoon current load for that ammo 
type. 

Line 22 Begins an inner loop over all the weapon systems in 
the platoon so that deliveries can be made. Loop ends on 
line 89. 
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Lines 24-27 Determine if any vehicle has sustained 

casualties, if so, the loop is cycled to the next weapon 
system . 

Lines 29-86 Check to see if the ammo delivered is one of 
the six carried on the TANK. If so, the weapon system's 
on-hand knowledge and actual knowledge is updated to 
reflect the delivery. 

Lines 88-39 Close the combat vehicle loop begun on line 22. 
Transfer of control goes to the next TANK or out to the 
next platoon. 

Lines 91-101 Update files by removing the request from 
company want lists and filing the same request on a 
supply request, simulating a request from battalion to 
the brigade ATP for more ammo. 

Line 102 Resets the delivery quantity to zero. 

Line 103 Closes out the platoon loop begun on line 12. 

Transfer of control is to the next, platoon or out to the 
next request. 

Line 104 Closes out the request loop begun on line 9. 
Transfer of control is to the next request or out. 

Lines 105-112 Cause every TANK in the company to update its 
ammo status. 
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Lines 114-116 Cause every platoon in the company to update 
its ammo status. 

Lines 117-118 Cause the company to update its ammo status. 
Lines 120-126 Turn the convoy around and sends it back to 
the battalion supply point as a resupply coming from the 
ATP. 

R. "EVENT REDISTRIBUTE" 

This event is scheduled from event MOVE. It is used to 
evenly redistribute ammunition in a platoon. 

ARG UMEN TS ( INTEGER) 

P - Holds the pointer value of the platoon currently 
redistributing . 

DISTR (DISTRIBUTOR) . Argument for the event REDISTRIBUTE 
holding the value of the unit's PLATOON. LEADER. 

DE FINE TO MEA N 

AMMO 1 . AP. TOW (ARMOR PIERCING/TOW ROUNDS). 

AMM02. HE. DRAG (HEAT/DRAGON ROUNDS). 

AMM03 . AW1 .OR. MSL3 (ALTERNATE WEAPON 1 OR MISSILE 3). 

AMM04 . AW2.0R. ADM (ALTERNATE WEAPON 2 OR AIR DEFENSE 

MISSILE) . 

GLOBAL VARIABLES ( INTEGER) 

PCL.V. ITEM 
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PCODE (PLATOON CODE) (2-d). Holds the pointer value for a 
platoon's PCL. V. ITEMS (PLATOON CLASS V ITEMS). 

TANK 

PER MANE NT ATTRIBUTE (REAL) 

TIME. V 

R E CIJR SI V E VAR IABLE (INT EGE R) 

CASSSTS. Current amount of an ammo type on-hand in a 
platoon. 

FLAG. Yielding argument for routine W.AMMO; not used in this 
routine. 

NO. BATTLE. Indicates whether RES.REQs should be filled. 

"0" indicates no 
"1" indicates yes 

BASSETS. Required amount of an ammo type based on the 
platoons stowed load. 

ROUTINES CALLED 

P. CLASS. V, UP. DATE, W.AMMO 

SETS USED 

PLAT. UNIT (PLATOON UNIT). Owned by a PLATOON . LEADER. Members 
are the unit’s combat vehicles (TANKS) . 

PLT. AMMO (PLATOON AMMUNITION). Owned by a PLATOON . LEADER. 
Members are the unit's PCL . V .ITEMS (PLATOON CLASS V 
ITEMS) . 

TEMPORA RY A TTRIBUTE (INTEGER) . 
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AMM05 (AMMUNITION 5). 

AMM06 (AMMUNITION 6). 

AP. TOW (ARMOR-PIERCING/TOW) . Ammunition 1 
TAC1 . (TANK AMMUNITION CODE 1). 

TAC2. (TANK AMMUNITION CODE 2). 

TAC 3 . (TANK AMMUNITION CODE 3). 

TAC4 . (TANK AMMUNITION CODE 4). 

TAC5. (TANK AMMUNITION CODE 5). 

TAC6 . (TANK AMMUNITION CODE 6). 

AW1 .OR . MSL3 (ALTERNATE WEAPON 1 OR MISSILE 3). Ammunition 3. 
AW2.0R. ADM (ALTERNATE WEAPON 2 OR AIR DEFENSE MISSILE). 

Ammunition 4. 

FKILL (FIREPOWER KILL). 

HE. DRAG (HEAT/DRAGON ROUNDS). Ammunition 2. 

KKILL (CATASTROPHIC KILL). 

MFKILL (MOBILITY AND FIREPOWER KILL) . 

MKILL (MOBILITY KILL). 

PAC (COMPANY AMMUNITION CODE). 

PCURR. LOAD (PLATOON CURRENT LOAD). On-hand balance for an 
ammo type. 

PL. B. LOAD (PLATOON BASIC LOAD). 

SLOAD1 (STOWED LOAD 1) . Optimal load ammo type 1. 

SLOAD2 (STOWED LOAD 2) . Optimal load ammo type 2. 
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SLOAD3 (STOWED 


LOAD 


3) . 


Optimal 


load 


ammo 


type 


3. 


SLOAD4 (STOWED 


LOAD 


4) . 


Optimal 


load 


ammo 


type 


4. 


SLOAD5 (STOWED 


LOAD 


5) . 


Optimal 


load 


ammo 


type 


5. 


SLOAD6 (STOWED 


LOAD 


6) . 


Optimal 


load 


ammo 


type 


6. 



PROGRAM LISTING 



1 EVENT REDISTRIBUTE (P) 

2 DEFINE NO. B AT TLE , R ASSETS ,CASSETS , ROUND, 

3 FLAG, AND ? AS INTEGER VARIABLES 

4 PRINT 1 LINE WITH TIME.V AS FOLLOWS 

EVENT REDISTRIBUTE CALLED AT TIME.V = S3 . **** 

5 • • 

6 FOR EVERY TANK IN PLAT . UNIT (P) , DO 

7 LET NO . 3ATTLE = 1 

8 CALL W. AMMO (TANK, NO. BATTLE) YIELDING FLAG 

9 LOOP 

10 ' « 

11 ri T T P PT A V fPI 

12 FOR EVERY PCL. V^ ITEM IN PLT. AMMO (P) , DO 

13 LET CASSETS = PC URR. LOAD f PCODE (P, ROUND) ) 

14 f| LET RASSETS = PL. B . LOAD (PCODE ( P, RO UND) ) 

16 FOR EVERY TANK IN PLAT .UNIT (P) , DO 

17 IF MKILL (TANK) =1 OR MFKILL (TANK) =1 

18 OR FKILL (TANK) =1 OR KKILL (TA NK) = 1 

19 CYCLE 

20 OTHERWISE 

21 IF TAC1 (TANK) = PAC (PCL. V. ITEM) 

22 LET AMMO 1 (TANK) = SLOAD1 (TANK) /R ASSET S^C ASSETS 

23 CYCLE 

24 ALWAYS 

25 IF TAC2 (TANK) = PAC (PCL. V. ITEM) 

26 LET AMM02 (TANK) = SLOAD1 (TANK) /RASSETS*CASSETS 

27 CYCLE 

28 ALWAYS 

29 IF TAC1 (TANK) = PAC (PCL. V . ITEM) 

30 LET AMM0 1 (TANK) = SLOAD1 (TANK) /RASSETS*CASSETS 

31 CYCLE 

32 ALWAYS 

33 IF TAC2 (TANK) = PAC (PCL. V. ITEM) 

34 LET AMM02 (TANK) = SLOAD2 (TANK) /RASS ETS^CASS ZTS 

35 CYCLE 

36 ALWAYS 

37 IF TAC3 (TANK) = PAC (PCL. V. ITEM) 

38 LET AMM03 (TANK) = SLOAD3 (TANK) /RASSETS^CASSETS 

39 CYCLE 

40 ALWAYS 

41 IF TAC4 (TANK) = PAC (PCL. V . ITEM) 

42 LET AMM04 (TANK) = SL0AD4 (TANK) /RAS SETS# CASS ETS 

43 CYCLE 

44 ALWAYS 

45 IF TAC5 (T ANK) = PAC (PCL . V . ITEM) 

46 LET AMM05 (TANK) = SL0AD5 (TANK) /RASSETS^CASSETS 

47 CYCLE 

48 ALWAYS 

49 IF TAC6 (TANK) = PAC (PCL. V. ITEM) 

50 LET AMM06 (TANK) = SLOAD6 (TANK) /RASSETS*CASSETS 

51 C YCL E 
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52 ALWAYS 

53 LOOP 

54 LOOP 

55 FOR EVERY TANK IN PLAT . UNIT (P) , DO 

56 LET NO. BATTLE = 1 

57 CALL W. AMMO (TANK, NO. BATTLE) YIELDING FLAG 

58 LOOP 

59 CALL P. CLASS. V 

60 RETURN 

61 END 

EXPLANA TION O F CODE 

Lines 2-3 Define recursive variables for use in the 
routine. 

Line 4 Prints a message marking the beginning of the 
routine. 

Lines 6-9 Update the platoon weapon system's current 
knowledge of its ammo status. 

Line 11 Updates the platoon's current ammo knowledge. 

Line 12 Begins the major loop for the routine by looping 

over all ammo types carried by the platoon. Loop ends on 
line 54. 

Lines 13-14 Capture the current assets on-hand and the 

required assets needed to be on-hand for computations. 
Line 16 Begins an inner loop for the routine looping over 
all weapon systems in the platoon. Loop ends on line 53. 
Line 17-20 Check if a weapon has sustained battle damage. 

If so, the routine cycles to the next weapon. 
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Lines 21-52 Check if the ammo being considered is one of 
the weapons six ammunitions carried. If so, the weapon 
is given a percentage of the assets on-hand equal to 
[weapon stewed load / platoon base load] multiplied by 
the platoon’s assets. 

Line 53 Closes out the inner loop causing the routine to 

loop to line 16 and the next weapon or out to the nexr 

ammo . 

Line 54 Closes out the major loop causing the routine to 

loop to line 12 and the next ammo type or out. 

Lines 55-58 Cause every TANK in the platoon to update its 
ammo status. 

Line 59 Causes the platoon to update its ammo status. 

S. "EVENT BN. ARRIVE" 

Event BN. ARRIVE is scheduled from CO .RESUPPLY. ARR to 
simulate an RSV or convoy returning to the battalion trains 
after a resupply mission. The RSV or convoy returns to the 
battalion trains with an identical cargo no what it 
delivered to the resupplied company. Understandably, this 
is unrealistic but it serves the purpose of resupplying the 
battalion trains in the model. This cargo is now added to 
the battalion's assets and becomes available for resupply 
again. 
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ARGUMENTS 

RCNVY (RESUPPLY CONVOY). Argument of the event 3N. ARRIVE 

(BATTALION ARRIVE) carrying the pointer of the convoy. 
EV ENT S SCHEDULED 
BN. ARRIVE (BATTALION ARRIVE). 

GLOBAL VARIAB LES (INTEGER) 

SCOPE (SUPPLY CODE) (2-d) . Holds the pointer value for a 
supply unit's SCL . V. ITEMS (SUPPLY CLASS V ITEMS). 

TANK 

PE RMA NENT ATTR IBU TES 

TIME. V 

SETS 

CARGO. Of a resupply truck. 

C.CGO . LIST (CONVOY CARGO LIST). Owned by a CONVOY. Members 
are the RES . REQs (RESUPPLY REQUEST) being shipped. 
ELEMENTS. Owned by a CONVOY. Members are trucks (TANKS) 
belonging to the convoy. 

5C0NV0Y (SUPPLY CONVOY). Owned by a S UPPL Y. OFEICER . Members 
are CONVOY (s) . 

SREQN. LIST (SUPPLY REQUISITION LIST). Of a RSS.REQ. 

TEMPORARY E NTI TIES 

CONVOY 

RES.RBQ. (RESUPPLY REQUEST) . 
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T.CGO (TRUCK CARGO) 



TEMPORARY ATT RIBUTES (INTEGER) 



C.MV. STATE (COMPANY MOVEMENT STATE). 



ONHAND 



RAC (RESUPPLY AMMO CODE). 



RFILL (RESUPPLY FILL). Attribute of a RES.REQ (RESUPPLY 



REQUEST) specifying the amount of ammunition released to 



fill a request. 



RP (RELEASE POINT). Attribute of a CONVOY specifying the 



convoy’s destination. 



RQTY (REQUIRED QUANTITY). Of a RES.REQ. 



ROUTINES CAL LED 



UP. DATE 



PR OGRAM LISTI NG 



1 EVENT BN.ARRIVE(RCNVY) 

2 DEFINE RCNVY AS AN INTEGER VARIABLE 

3 PRINT 1 LINE WITH TIME.V THUS 

EVENT BN. ARRIVE CALLED AT TIME.V = *#.*#** 

4 LET C. MV. STATE (RCNVY) = 0 

5 FOR EVERY RES.REQ IN C .CGO. LIST (RCNVY) , DO 

6 ADD RFILL (RES. REQ) TO 

7 ONHAND (SCODE (RP (RCNVY) ,RAC (RES.REQ) ) ) 

8 REMOVE RES.REQ FROM C . CGO. LIST ifiCNVY) 

9 REMOVE RES.REQ FROM SREQN .LIST (RP (RCNVY) ) 

10 IF RQTY ( RES . REQ) = 0, 

11 DESTROY RES.REQ 

12 ALWAYS 

13 LOO? 

14 FOR EVERY TANK IN ELEMENTS (RCNVY) , DO 

15 FOR EVERY T.CGO IN CARGO (TANK) , DO 

16 REMOVE T.CGO FROM CARGO (TANK) 

17 DESTROY T.CGO 

18 LOOP 

19 REMOVE TANK FROM ELEM ENTS (RCN V Y) 

20 LOOP 

21 REMOVE RCNVY FROM SCONVOY (RP (RCNVY) ) 

22 DESTROY CONVOY CALLED RCNVY 

23 RETURN 

24 END 
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EXPLANAT ION OF CODE 



Line 2 Defines recursive variables used in the routine. 

Line 3 Prints a message indicating that the routine has 
been called. 

Line 4 Changes the convoy move state to zero. 

Lines 5-13 Loop over every resupply request in the convoy 
adding its fill to the on-hand stocks at the battalion, 
removing it from the convoy cargo list and the S-4's 
request list. If the out standing balance for the 
request is zero it is destroyed. 

Lines 14-20 Loop over every TANK in the convoy's elements 
removing the cargo entities from the trucks, and the 
trucks from the convoys. The cargo entity is then 
destro yed . 

Lines 21-22 Remove the convoy from the S-4's list and 
destroys the convoy. 

T. "EVENT 0P.M. AMMO" 

Event 0P.M. AMMO is initially scheduled in routine 

BLU. CREATE for each weapon system in the model. It is used 

to call routine tf.AMMO for a periodic update of ammo LONs. 

It subsequently randomly reschedules itself simulating the 
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irregular counting of ammunition during combat. Based on a 
returning argument from routine W. AMMO , this event may 
schedule 3. platoon update if the weapon is critical for an 
ammo type, or may stop scheduling updates for the weapon if 
damage has been sustained. 

ARGUMEN T f I NTEGER) 

RND.CNTR. Points to weapon currently updating. 

GLOBAL VARIABLE (INTEGER), 

WSTREAH (WEAPON RANDOM NUMBER STREAM). 

GLOBAL VA RIA BLES (REAL) 

WMAX (WEAPON MAXIMUM). The maximum time that can pass before 
a weapon will update its ammunition status. 

WMIN (WEAPON MINIMUM). The minimum time that can pass before 
a weapon will update its ammunition status. 

RSCUSIV E V ARIABLE S (INTEGER) 

FLAG. Yielding argument from W.AMMO. 

ROUTINE S CALL ED 

UNIFORM. F, UP .PLT. AMMO (UPDATE PLATOON AMMO) 

PE RMA NE NT A TTRIBUTE (REAL) 

TIME. V 

TEMPORA RY ATTRIB UTE (IN TEG ER) 

A - Holds pointer of weapon currently updating. 

PLTLDR . Of TANK. 
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P.RND. CNTR (PLATOON ROUND COUNTER). Argument of event 



UP. PLT. AMMO pointing to a specific platoon which will 



update . 



PROGR AM LISTI NG 



1 EVENT OP.W. AMMO(A) 

2 DEFINE NO. BATTLE. A, AND FLAG AS INTEGER VARIABLES 

3 LET NO. BATTLE = 0 

4 CALL W. AMMO GIVEN A. NO. BATTLE YIELDING FLAG 

5 IF FLAG = 100, * ' EMERGENCY RESUPPLY NEEDED 

6 SCHEDULE AN UP . PLT . A MMO (PLTLDE (A) ) NOW 

7 PRINT 2 LINES WITH TIME.V THUS 

UP. PLT. AMMO CALLED BECAUSE OF ZERO BAL 
TIME.V = 3*.**S* 

8 ALWAYS 

9 IF FLAG NE 1, '• NO BATTLE DAMAGE SUSTAINED 

10 SCHEDULE AN UP. W. AMMO (A) 

11 IN UNIFORM. F (WMIN, WM AX, WSTREAM) HOURS 

12 ALWAYS 

13 RETURN 

14 END 

EXPLANA TION O F CODE 



Line 2 Defines recursive variables for the routine. 



Line 3-4 Set the index necessary to call for a battle 



update and calls routine W.AMMO. 



Lines 5-8 If the flag returned indicates that a weapon is 



at empty for an ammunition type, this provokes a call 



for the platoon to update its ammo. 



Lines 9-11 If the flag indicates that no battle damage has 



been sustained, the update is rescheduled. 



U. "EVENT UP. PLT. AMMO" 



This event is initially scheduled from routine 



BLU. CREATE to call routine P. CLASS. V for a periodic ammo 
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update. It then randomly reschedules itself in order to 
simulate a platoon leader checking individual weapons. 
Scheduling also occurs if a weapon reaches an LON of 11 1" for 
an ammunition type simulating the initiation of an emergency 
request. Additionally, based on a return argument from 
routine P. CLASS. V, this event may schedule a company update 
if the platoon is critical for an ammo type, or may stop 
scheduling updates for the platoon if all its weapons are 
incapacitated. 

A RGUM ENT (INTEGER) 

P.RND.CNTR (PLATOON ROUND COUNTER). Argument of the event 
UP. PLT. AMMO (UPDATE PLATOON AMMUNITION) carrying the 
pointer value of the platoon currently updating. 

SET 

PLT. AMMO (PLATOON AMMUNITION). Owned by a PLATOON . LEAD ER. 
Members are the unit's PCL . V. ITEMS (PLATOON CLASS V 
ITEMS) . 

EV ENT NOTICE 

UP.COM. AMMO(UPDATE COMPANY AMMUNITION). 

GL OBA L VARI ABLE (INTEGER) 

PSTREAM (PLATOON RANDOM NUMBER STREAM). 

GLOBAL VARIABLES (REAL) 
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PMAX (PLATOON MAXIMUM) . The maximum time a that can pass 
before a platoon will update its ammunition status. 

PMIN (PLATOON MINIMUM) . The minimum time a that can pass 
before a platoon will update its ammunition status. 
PERMAN ENT AT TRIBUTES (INTEGER) 

PCO.CDR (PLATOON COMPANY COMMANDER). 

N.PCL. V. ITEMS (NUMBER OF PLATOON CLASS V ITEMS). 

PE RMA NE NT ATT RIBUTE ( REA L) 

TIME . V 

RECURSI VE VAR IABLE (INTEGER) 

FLAG. Yielding argument from P. CLASS. V. 

RO UTINES 

P. CLASS. V(PLATOON CLASS V AMMO), UNIFORM. F 
TE MPORA RY A TTR IBUTE (INTEGER) 

C.RND. CNTR (COMP ANY ROUND COUNTER). Argument of the event 
UP . COM. AMMO (UPDATE COMPANY AMMUNITION) carrying the 
pointer value of the company currently updating. 

J - Points to platoon currently updating. 

PROGRAM LISTING 

1 EVENT UP.PLT. AMMO (J) 

2 DEFINE J, FLAG AS INTEGER VARIABLES 

3 CALL P. CLASS. V GIVEN J YIELDING FLAG 

4 IF FLAG = 1, 

5 SCHEDULE AN UP . COM . AMMO (PCO. CD R ( J) ) NOW 

6 PRINT 2 LINES WITH TIME. V THUS 

UP. COM. AMMO CALLED BECAUSE OF ZERO BAL 
TIME. V = $=*.**$* 

7 ALWAYS 

8 IF FLAG NE N . PCL . V . ITEMS (J) , ' • PLATOON STILL VIABLE 

9 SCHEDULE AN UP . PLT. AMMO ( J) 
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10 IN UNIFORM. F (PMAX , PMIN ,PSTREAM) HOURS 

11 ALWAYS 

12 RETURN 

13 END 

EX PLA NAT ION OF CO DE 

Line 2 Defines the recursive variables used in the routine. 
Line 3 Calls upon routine P. CLASS. V to update the platoon's 
ammo status. 

Lines 4-7 If the flag equals 1, this indicates that the 
platoon is at zero balance for an ammo type and the 
company is requested to update its ammo status. 

Lines 8-11 If the flag does not indicate than the platoon 
has sustained enough damage to place it out of combat, 
its next update is established. 

V. "EVENT UP.COM. AMMO" 

Event UP. COM. AMMO is initially scheduled from routine 
3ASIC. LOAD and subsequently randomly reschedules itself 
simulating the update of ammunition assets within a company. 
It is also called immediately if a platoon reaches an LON of 
"1" for an ammunition type simulating the initiation of an 
emergency request. Additionally, based on a returned 
argument from routine COM. AMMO, this event may stop 
scheduling updates if all its platoons have been put hors de 
combat. 

AR GUME NTS 
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C.RND.CNTR (COMPANY ROUND COUNTER). Argument for event 
UP. COM. AMMO (UPDATE COMPANY AMMUNITION) holding a 
pointer of a company unit. 

EVENTS SCHEDULED 
UP.COM. AMMO 

GL OBA L VARIABLES (REAL) 

CMAX (COMPA NY MAXIMUM). The maximum time that can pass before 

a company will update its ammunition status. 

CMIN (COMPANY MINIMUM) . The minimum time that can pass before 

a company will update its ammunition status. 

CSTREAM (COMPANY RANDOM NUMBER STREAM). 

PERMANEN T AT TRIBUTES (INTEGER) 

N.CCL.V. ITEMS (NUMBER COMPANY CLASS V ITEMS). 

RECURSIV E VAR IABLES (INTEGER) 

C - Points to company updating. 

FLAG. Yielding argument of routine COM. AMMO. 

NO. BATTLE. Indicates whether RES.REQs should be filled. 

"0" indicates no 
"I” indicates yes 
RO UTI NES CALL ED 

COM. AMMO (COMPANY AMMO), UNIFORM. F 
PR OGR AM LIS TING 

1 EVENT UP.COM. AMMO (C) 

2 DEFINE NO. BATTLE, C, FLAG AS INTEGER VARIABLES 

3 LET NO. BATTLE = 0 

4 CALL COM. AMMO GIVEN C, NO. BATTLE YIELDING FLAG 
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5 IF FLAG NS N . CCL . V . ITEMS (C) , 

6 SCHEDULE A UP . COM. AMMO (C) 

7 IN UNIFORM. F (CHIN, CM AX ,CSTREAM ) HOURS 

8 ALWAYS 

9 RETURN 
10 END 

EXPLANATION OF CODE 



Line 2 Defines the recursive variables used in the routine. 



Lines 3-4 Set the indicator flag to require requisitions to 



be filed and calls routine COM. AMMO. 



Lines 5-8 If the indicator flag returned indicates that the 



company is still a viable combat entity, its next update 



is scheduled. 



W. "EVENT B. UP. DATE" 



Event 3. UP. DATE is initially scheduled in the main 



program to initiate a periodic call for a battle summary 



from routine UP. DATE. This event subsequently reschedules 



itself every 24 hours. 



PERM ANE NT ATT RIBUTE 



TIME. V 



ROUTINES CALLED 



TRUNC.F, UP. DATE 



PROGRAM LISTI NG 



1 EVENT B. UP. DATE 

2 CALL UP. DATS 

3 SCHEDULE A B. OP. DATE AT TRUNC. F ( TIME . V) + 1 

4 RETURN 

5 END 

E XPL ANATION OF CODS 
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Lins 2 Calls routine UP. DATE to print a battle summary. 

Line 3 Schedules another update in 24 hours. 

X. "EVENT STOP . SIMULATION" 

Event STOP. SIMULATION is called from the main program at 
the scheduled time to stop the simulation. It causes a 
final printout of the battle summary to be produced. 
PE RMA NE NT A TT RIB UTES (REAL) 

TIME. V 

RO UTIN ES CALL ED 

UP. DATE 

PR OGR AM L ISTI NG 

1 EVENT STOP. SIMULATION 

2 LIST TIME.V 

3 CALL UP. DATE 

4 STOP 

5 END 

E XPLANATION O F CODE 

Line 2 Prints the time the simulation ended. 

Line 3 Calls routine UP. DATE to print a final battle 
summary. 

Y. "EVENT UP. S 4. AMMO" 

This event is scheduled by event COM. AMMO when a 
resupply request is created. The purpose of event 
UP. S4. AMMO is to process requests for and issue ammo from 
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the battalion's reserve stocks of ammunition. In execution, 
the event performs the following functions: prioritization 
of outstanding requests; assessment of quantities to be 
released to fill requests subject to transportation 
availability; creation of convoys to carry the supplies; 
creation of cargo manifests for individual trucks; and the 
dispatch of convoys from the supply point. Lastly, the 
event schedules the convoy arrival (CO. RESUPPLY. ARR) . 
ARGUMENTS 

ISSUEE. Argument for the routine containing the unit 
requesting resupply. 

ISSUER. Argument for the routine containing the pointer of 
the supply officer updating. 

GLOBAL VA RIAB LES (INTEGER) 

SCODE (SUPPLY CODE) (2— d) . HOLDS POINTER FOR SCL.V.ITEM. 

GL OBAL V ARIAB LES (REAL) 

CL1 .PCT (CRITICAL L0N1 PERCENT). 

CL2.PCT (CRITICAL L0N2 PERCENT). 

MAX. TRIP. Maximum travel time to a unit. 

MIN. TRIP. Minimum travel time to a unit. 

SCODE (SUPPLY CODE). 

PE RMA NE NT ATT RIBUTES (INTEG ER) 

N. SCON 70 Y (NUMBER IN SUPPLY CONVOY). 
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N.SWANT. LIST (NUMBER IN SUPPLY WANT LIST) . 



SCO. CDR (SUPPLY COMPANY COMMANDER). 

PE RMA NENT ATTRIBUTE (REAL) 

TIME. V 

RE CURS IV E VAR IABLES (IN TEG ER). 

A - Holds pointer to S-4 updating. 

COM. Holds pointer to company updating. 

CON . ID (CONVOY ID). Holds the pointer value of the convoy 
currently being filled. 

IT. LIVES. Indicates if a convoy has already been created to 
carry supplies to a particular unit. 

I - Loop index. 

K - Loop index. 

N. ENDS (NUMBER OF ROUNDS). Holds the number of rounds being 
released to fill a request. 

RC. TEMP (ROUND/CUBE TEMPORARY). Holds the computational value 
of the number of rounds that may be loaded on a truck 
due to cube restrictions. 

RNDS (ROUNDS) . Holds the number of rounds being released to 
fill a request. 

RR (RESUPPLY REQUEST). Holds the pointer of the resupply 
request being currently filled. 
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RW. TEMP (ROUND/WEIGHT TEMPORARY). Holds the computational 
value of the number of rounds that may be loaded on a 
Truck due to weight restrictions. 

T. COUNT (TRUCK COUNT). Holds the value of the number of 

trucks already loaded for a particular resupply request. 

TRKS. AVAIL (TRUCKS. AVAILABLE) . Holds the total number of 

trucks available for assignment to a resupply mission. 

CU (CUB E) . Holds the maximum cube that may be leaded on a 
resupply vehicle. 

CU. AVAIL (CUBE AVAILABLE). Holds the total cube capacity that 
is available within the supply unit for the shipment of 
supplies. 

CU. REQ (CUBE REQUIRED). Holds the total cube that is required 
in order to ship a resupply request. 

L0N1. Variable which indicates whether Level of Need 1 

requests are currently filed with the supply officer. 

L0N2. Variable which indicates whether Level of Need 2 

requests are currently filed with the supply officer. 

MUL 1 (MULTIPLIER 1) . Holds the multiplier for LON 1 requests 
which is used to reduce the fill on such requests. 

MUL2 (MULTIPLIER 2) . Holds the multiplier for LON 2 requests 
which is used to reduce the fill on such requests. 



240 



MULT (MULTIPLIER) . Holds the multiplier for both LON 1 and 
LON 2 requests in the main part of the computations. 
PCT (PERCENTAGE) . Holds the percentage value of the amount 
released to fill a request versus the total quantity 
requested. 

RCU (RESIDUAL CUBE). The cube remaining in a CONVOY to be 



RWT (RESIDUAL WEIGHT). The weight remaining in a CONVOY to be 
filled. 

WT (WEIGHT) . Holds the maximum weight that may be loaded on a 
resupply vehicle. 

WT. AVAIL (WEIGHT AVAILABLE). Holds the total weight capacity 
that is available within the supply unit for the 
shipment of supplies. 

WT. REQ (WEIGHT REQUIRED). Holds the total weight that is 
required in order to ship a resupply request. 



filled 



ROUTINE S CALL ED 



FILE. UPDATE 



LOAD. THE. TRUCK 



MAX . F 

PRI. RESUPPLY 



TRUNC.F 



MIN.F 



UNIFORM. F 



UP. DATE 



WT. AND. CUBE 
SETS 
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C.CGO . LIST (COMPANY CARGO LIST). Contains a master listing of 
the RES.REQs that are loaded on the trucks belonging to 
the set ELEMENTS (of a convoy) . 

CARGO. Contains a listing of the T.CGO loaded on a 
particular truck. 

CWANT. LIST (COMPANY WANT LIST). Contains a listing of all 
outstanding RES.REQs belonging to a company. 

SCONVOY (SUPPLY CONVOY). Contains a listing of all CONVOYs 
the supply officer currently has active. 

SWANT. LIST (SUPPLY WANT LIST). A list of all outstanding 
requests the supply officer has. 

TEMPORA RY ENT ITIES 

CONVOY. An entity created to move supply trucks (TANKs) . 
around the battlefield with supplies. It contains the 
set ELEMENTS which holds the pointers of the trucks 
assigned to the mission. 

RES. REQ (RESUPPLY REQUEST). 

T.CGO (TRUCK CARGO). An entity created to identify the cargo 
loaded on a supply truck (TANK) . 

TEMPORARY ATTRIBUTES (ALPHA) . 

RNO MEN (RESUPPLY NOMENCLATURE). Attribute of an SCL.V.ITEM 
containing the name of the particular ammo type. 
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STATUS. Transmits information as to where a RZS. REQ is in 

relation to the supply system. Values can be: T0S4, ATP, 
TOCO. 

T NO MEM (TRUCK NOMENCLATURE) . Contains the name of a 

particular ammo type. 

TEMPORARY_ATTRIBUT2S_iINTEGER)_ 

C.MV. STATE (CONVOY MOVEMENT STATE). Indicates if a convoy is 

in transit between supply points. 

"O'* indicates no 
"1" indicates yes. 

CO. CNVY (COMPANY CONVOY). Argument of the routine 

CO . RES UPPLY . ARR holding the pointer of the convoy 
arriving . 

CONTRKS (CONVOY TRUCKS). Contains the number of trucks 
assigned to a convoy. 

CPNTR (CONVOY POINTER). Holds the pointer value for an active 
CONVOY. 

L. ELEMENTS (LAST ELEMENT). System variable pointing at the 

last truck in a CONVOY'S ELEMENTS set. 

M. C.CGO. LIST (MEMBER CCNVOY CARGO LIST). System generated 

attribute which indicates whether a RES. REQ is filed in 
a convoy. 
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MANIFEST. Holds the pointer of the CONVOY a RES. REQ is 
loaded on. 

N.C.CGO.LIST (NUMBER IN COMPANY CARGO LIST). Indicates the 
total number of RES.REQs filed in a CONVOY. 

N. CARGO (NUMBER IN CARGO). Indicates the total number of 
T.CGO items loaded on a particular t.ruck. 

N.T. ALLOC (NUMBER OF TRUCKS ALLOCATED). Contains the number 
of trucks to be allocated to move the rounds released 
for a resupply reguest. 

ONHAND. Holds the on-hand balance for rounds of a particular 
ammo type at the resupply point. 

RAC (RESUPPLY AMMUNITION CODE). 

RDS.PKG (ROUNDS PER PACKAGE). 

REQUESTOR. Contains the pointer to the unit requesting 
resupply. 

RFILL (REQUEST FILL). Holds the number of rounds released to 
fill a request. 

RP(RELEASE POINT). Convoy termination point. 

RQTY (REQUIRED QUANTITY). 

RRPNTR (RESUPPLY REQUEST POINTER). 

SCREEN. Indicates whether a request has been reviewed during 
a particular S-4 update cycle. 

SP (START POINT). Convoy start point. 
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SPACE. Indicates if empty space remains on trucks within a 



CONVOY. 



SPRIORITY (SUPPLY PRIORITY) . Indicates the urgency of need on 



a RES . REQ . 



TCU (TRUCK CUBE) . The cube that a truck has available to be 



filled. 



TPNTR (TRUCK POINTER). 



TQTY (TRUCK QUANTITY). Holds the number of rounds within a 



T.CGO that are loaded on a truck. 



TRAC (TRUCK AMMUNITION CODE). Of a T.CGO item. 



TWT (TRUCK WEIGHT). The weight that a truck has available to 



be filled. 



T EMPOR ARY ATTRIBUTES (R EAL ) 



CU.PKG(CUBE PACKAGE). Of a standard package of ammo. 



WT. PKG (WEIGHT PACKAGE). Of a standard package of ammo. 



PROGRAM LISTI NG 



1 EVENT UP. S4. AMMO (A, COM) 

2 DEFINE R.RNDS,A,I,K,COM,RW.TEMP,RC.TEMP,RNDS, 

3 IT.LIVES,T. COUNT ,N.RNDS,CON. ID, RR, 

4 AND TRKS. AVAIL AS INTEGER VARIABLES 

5 DEFINE MUL1,MUL2,LON1,LON2,CU,CU. AVAIL, CU . REQ , PCT , 

6 MULT, WT,WT. AVAIL, WT. REQ , RWT , RCU AS REAL VARIABLES 

7 PRINT 1 LINE WITH TI ME . V AS FOLLOWS 

EVENT UP. S4. AMMO CALLED AT TIME.V = *#.*** 

8 • • 

9 CALL FILE. UPDATE (A, COM) 

10 CALL WT. AND. CUBE GIVEN A 

11 YIELDING WT. AVAIL, CU. AVAIL, TRKS. AVAIL, WT,CU 

12 "TEST IF RESUPPLY MISSIONS ARE POSSIBLE 

13 • » 

14 IF TRKS. AVAIL = 0 

15 RETURN 

16 OTHERWISE 

17 « • 

18 CALL PRI. RESUPPLY GIVEN WT. A VAIL ,CU. AVAIL , A 

19 YIELDING MUL 1 , MUL2 , LON 1 ,LO N 2 
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20 

21 

22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

43 

49 

50 

51 

52 

53 

54 

55 

56 

57 

58 

59 

60 

61 

62 

63 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 

81 

82 

83 

84 

85 

86 

87 



i • 



•REQUEST' 

"CHECK RES. REQ BY LON, 3Y CRITICALITY, BY TIME 
FOR I = 1 TO 5, DO 

• i 

"ID AND LOOP OVER REQ FROM THE MOST CRITICAL UNIT 
FOR EVERY RES. REQ IN SWANT . LIS 1 ( A) 

WITH SPRIORITY (RES. REQ)=I 
|( AND M.C.CGO .LIST (RES. REQ) = 0, DO 

• 'CHECK SCREEN 
IF SCREEN (RES. REQ) = 1, 

CYCLE 

OTHERWISE 

LET SCREEN (RES. REQ) = 1 

''DETER IF THE AMMO IS ON-HAND AT SUPPLY POINT 
IF ONHAND (SCODE (A, BAC(RES. REQ) ) ) EQ 0 
CYCLE 
ALWAYS 

i i 

" SET MULTIPLIERS 

LET MULT = 1.0 

IF SPRIORITY (RES. REQ) = 1, 

LET MULT = MUL 1 
ALWAYS 

IF SPRIORITY (RES. REQ) = 2, 

LET MULT = MUL 2 
ALWAYS 

< • 

" DETER IF THERE IS ENOUGH AMMO TO MEET REQMNTS 
LET N.RNDS = RQT Y (RES. REQ) * MULT 
LET R.RNDS = RQT Y ( RES. REQ) 

IF N.RNDS GT ONH AN D (SCODE ( A , RAC ( RES. REQ) ) ) 

LET N.RNDS = ONH AND (SCODE ( A, RA C (RES . REQ) ) ) 
ALWAYS 

i • 

''DETERMINE THE WT AND CUBE TO BE SHIPPED 



• • 



i • 



LET WT. REQ=N. RNDS* WT . PKG (SCO DE ( A , RAC { RES . REQ) ) ) 
/RDS. PKG (SCODE (A, R AC (RES. REQ) ) ) 

LET CU . RE Q= N . RN DS*CU. PKG (SCODE ( A , RAC (RES . REQ) ) ) 
/RDS. PKG (SCODE ( A, RAC (RES. REQ) ) ) 

" DETER IF A UNIT CONVOY IS ALREADY FORMED 
FOR EVERY CONVOY IN SCONVOY(A) 

WITH C. MV . STATE (CONVOY) = 0 AND SP(CONVOY) = A 
AND RP (CONVOY) = REQUESTOR (RES. REQ) . DO 

''CAPTURE THE POINTER VALUE OF THE CONVOY 



LET CON. ID = CONVOY 
LET IT. LIVES = 1 



' 'CHECK 
IF SPACE 
IF WT 
OR 
LET 
LET 
LET 



IF SPACE 
(CONVOY) 
REQ GT T 
CU .REQ 



IS AVAIL OH 
= 1 

WT (L. ELEMENTS 
GT TCU (L. ELEME 



CONVOY TRUCKS 



(CONVOY) ) 
NTS (CON VO 
CONVOY 



RWT = TWT (L. ELEMENTS ( 

RCU = TCU (L. ELEMENTS (CONVOY 



RW . TEMP= RWT 

/WT. PKG (SCODE 

* RDS. PKG (SCODE 
LET RC.TEMP = RCU 

/CU. PKG (SCODE 

* RDS. PKG (SCODE 
RNDS = MIN. F (RW. TEMP, 
SPACE (CONVOY) = 0 



li 



Y)) 



(A, RAC (RES. REQ) ) ) 
(A/3AC (RES. REQ) ) ) 



LET 

LET 

ELSE 

LET 

ALWAYS 



I 



A, RAC (RES. REQ) ) ) 
A, RAC (RES. REQ) ) ) 
C.TEMP) 



RNDS = N.RNDS 
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88 

89 

90 

91 

92 

93 

94 

95 

96 

97 

98 

99 

100 

101 

102 

103 

104 

105 

106 

107 

108 

109 

1 10 

111 

111 

112 

113 

114 

115 

1 16 

117 

118 

119 

120 

121 

120 

121 

122 

123 

124 

125 

126 

127 

128 

129 

130 

131 

132 

133 

134 

135 

136 

137 

138 

139 

140 

141 

142 

143 

144 

145 

146 

147 

148 

149 

150 

151 



i • 



t • 



t i 



• i 



• • 



IF RNDS le 0, 
go to endfill 
otherwise 

CREATE A T.CGO 

LET TPNTR (T.CGO) = L. ELEMENTS (CONVOY) 

LET RRPNTR (T.CGO) = RES. REQ 

LET TNOMEN (T.CGO) = R NOMEN (RES . REQ) 

LET TRAC (T.CGO) = RAC (RES. REQ) 

LET TQTY (T.CGO) = RNDS 

FILE T.CGO IN CARGO (L. ELEMENTS (CONVOY) ) 
••REDUCE THE QUANTITY ON THE RES. REQ 
LET N. RNDS = N .RNDS - RNDS 



LET RFILL (RES. REQ) = RFILL (RES . REQ) + RNDS 
LET RQTY (RES. REQ) = RQ TY (R ES . REQ) - RNDS 
'•REDUCE THE ON-HAND BALANCE OF STOCKS 
LET ON HAND (SCODE (A, RAC (RES. REQ) ) ) = 

ONHAND (SCODE (A, RAC (RES. REQ) ) ) -RNDS 
"REDUCE THE WEIGHT AND CUBE FOR THE REQ 
LET WT . REQ= TRUNC . F ( WT . REQ - RNDS 

* WT. PKG (SCODE ( A , RAC ^RES . REQ j j j 



/RDS.PKG (SCODE (A, RAC (RES. REQ) 

LET CU.REQ= TRUNC. F (CU .REQ - RNDS 

'SCODE (A r RAC (RES. REQ) ) j 



• i 



REDUCE 



*CU.PKG 
/RDS.PKG (i 
THE WT AND 
TRUCK 



CODE (A , RAC (RES. REQ) ) 
CUBE AVAIL ON THE 



LET TWT (L. ELEMENTS (CONVOY) ) = 

TRUNC. F (TWT (L. ELEMENTS (CONVOY) ) 

- RNDS^WT. PKG (SCODE ( A , RAC (RES . REQ) ) ) 
/RDS.PKG (SCODE (A, RAC (RES. REQ) ) ) ) 

LET TCU (L. ELEMENTS (CONVOY) ) = 

TRUNC. F (TCU (L. ELEMENTS (CONVOY) ) ) 

- RN DS# WT. PKG (SCODE (A.RAC (RES . REQ) ) 
/RDS.PKG (SCODE (A, RAC (RES. REQ) ))) 



ALWAYS 

• 'FILL IN CONVOY 
IF CON. ID IS NOT 
FILE CON. ID IN 
AT U A Y ^ 

IF RES. REQ NOT IN 
FILE RES. REQ IN 
ALWAYS 



MANIFEST 
IN SOME SCONVOY 
SCONVOY (A) 

C.CGO. LIST , 

C.CGO. LIST (CON. ID) 



LET MANIFEST (RES. REQ) = CON. ID 
LET STATUS (RES. REQ) = "TOCOMEANY" 

IF RQTY (RES. REQ) = 0 
GO TO REQUESTLOOP 
OTHERWISE 
ALWAYS 

' END. SPACE. CHECK • LOOP 
• RALLY ' 

"CHECK NUMBER OF TRUCKS AVAIL FOR SHIPMENT 
IF TRKS. AVAIL EQ 0 
GO TO FINALCHECK 
OTHERWISE 

"IF A CONVOY DOESN'T EXIST CREATE ONE 
IF IT. LIVES EQ 0 
CREATE AN CONVOY 
LET CPNTR (CONVOY) = CONVOY 
LET CON. ID = CONVOY 

LET RP (CONVOY) = REQUESTO R (RES . REQ ) 

LET SP (CONVOY) = A 
ALWAYS 

"DETERMINE THE # OF TRKS ARE ON-HAND 
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210 



Lines 



• ' IF NOT ADJUST 

IF WT.3EQ LT WT. AVAIL AND CU.REQ LT CU. AVAIL, 

LET N. T . ALLOC (RES . EEQ) = 

TRUNC.F (M AX . F (WT . REQ/ WT,C U . REQ/CU) +1) 

ELSE 

LET N.T. ALLOC (RES. REQ) = TRKS. AVAIL 
ALWAYS 

LET TRKS. AVAIL = TR KS. AVAIL- N . T . ALLOC (RES . REQ) 

’’FILL IN CONVOY MANIFEST 
IF CON. ID IS NOT IN SOME SCONVOY 
FILE CON. ID IN SCONVOY (A) 

ALWAYS 

IF RES. REQ NOT IN C.CGO.LIST, 

LET STATUS (RES. REQ) = "TOCOMPANY" 

FILE RES. REQ IN C . CGO . LIST (CON . ID) 

ALWAYS 

LET MANIFEST (RES. REQ) = CON. ID 

ADD N. T. ALLOC (RES. REQ) TO CO NTRKS (CO N . ID) 

LET RR = RES. REQ 
CALL LOAD. THE. TRUCKS 

(A,RR,WT. REQ, CU.REQ, N . RN DS ,CO N . ID) 

" ADJUST THE WT . AND CUBE AVAIL FOR SHIPPING 
CALL WT. AND. CUBE GIVEN A 

YIELDING WT. AVAIL, CU. AVAIL ,TRKS.AVAIL,WT,CU 

• « 

• REQUESTLOOP * 

••UPDATE SWANT . LIST FILES 
LET PCT = R. RNDS/RQTY (RES. REQ) 

IF (SPRIORITY (RES. REQ) = 1 AND PCT GT C. L 1 PCI) 
ORfSPRIORITY (RES. REQ) = 2 AND PCT GT C.L2PCT) 
REMOVE RES. REQ FROM SW ANT . LIST (A) 

ELSE 

REMOVE EES. REQ FROM SW ANT . LIST (A) 

ALWAYS 

t « 

LET IT. LIVES = 0 

• i 

LOOP 

LOOP 

« « 

•‘DISPATCH ALL CONVOYS CREATED 
FOR EVERY CONVOY IN SCONVOY (A) 

WITH C. MV.STATE(CONVOY) =0 AND SP (CONVOY) =A, DO 
LET C. MV. STATE (CONVOY) = 1 

LOOP 

« « 

IF CON. ID NE 0. 

SCHEDULE A CO. RESUPPLY. ARR (CON .ID) 

IN UNIFORM. F (MINTRIP,M AXTRIP ,TSTREAM) MINUTES 
ALWAYS 

i « 

• • RESET LOOP CHECKS 

FOR ALL RES. REQ IN CWANT .LIST (SCO. CDS (A) ) , DO 
LET SCREEN (RES. REQ) = 0 
LOOP 
RETURN 
END 

E XPLANA TION OF CODE 



2-6 Define recursive variables for the routine. 



Line 7 Prints a message marking the beginning of the event. 
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Line 9 Calls routine FILE. UPDATE which files new requests 
and checks old requests for duplication. 

Lines 10-11 Calls routine WEIGHT. AND. CUBE to assess the 
total weight and cube capacity available to handle 
shipments of supplies forward. 

Lines 13-16 Check if all resupply vehicles are already in 
use. If so, the routine is ended with no further action 
taken. 

Line 18-19 Calls routine PRI. RESUPPLY to determine if LON1 
and L0N2 requests should be modified in order to fill 
more requests with a lesser amount of ammo. 

Lines 21-23 Start the major loop of the routine. Initialize 
an index to the most urgent LON a resupply request can 
have and begin the loop which will fill requests. Loop 
ends on line 192. 

Lines 25-28 Start an inner loop of the routine to identify 
the most critical resupply request on-hand to fill 
first. Loop ends on line 191. 

Lines 30-34 Check the screen attribute of a resupply 

request to determine if the request has been reviewed 
before in the current cycle. If the request has been 
reviewed, the request is cycled. 
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Lines 36-39 Check the availability of the ammo requested at 
the supply point. If none is available the request is 
cycled . 

Lines 41-48 Set multipliers for high priority requests as 
appropriate. The purpose of the multipliers is to 
reduce the fill on high priority requests in order to 
release truck space to fill mere high priority requests. 

Lines 50-55 Determine if there is enough ammo available zo 
fill requests. If not, the request is filled with whan 
is available. 

Lines 57-61 Determine the weight and cube needed to ship 
the number of rounds requested. 

Lines 63-66 Start an inner loop which checks to see if a 
convoy is already formed for requestor of the current 
request. If one exists, this loop is entered and any 
available space on trucks already committed to the 
convoy is filled before more trucks are committed. Loop 
ends on line 134. 

Line 68 Captures the pointer value of the convoy formed. 

Line 69 Initializes a variable signifying that a convoy is 
already formed for the unit. 
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Lines 72-128 Perforin an I? check to determine if space is 
still available on convoy trucks. If so, the logic 
embedded to line 133 is executed; if not, control is 
transferred to line 133. 

Lines 73-87 Perform an IF check to compute the number of 
rounds that may be shipped on the convoy subject to the 
available weight and cube. Satisfying the IF condition 
indicates that the current request will fill the room 
available. Transfer to the ELSE condition indicates that 
the request will leave space on trucks for additional 
requests. 

Line 75 Computes the residual weight available on the 
convoy . 

Line 76 Computes the residual cube available on the convoy. 

Lines 77-79 Compute the rounds that may be shipped for a 
request subject to the weight limitations of the truck. 

Lines 80-82 Compute the rounds that may be shipped for the 
request subject to the cube limitations of the truck. 

Line 33 Specifies the number of rounds to be released 
subject to the minimum restriction. 

Line 84 Sets the space attribute of the convoy to indicate 
that there is no space available. 
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Lines 85-86 Mark the ELSE logic which indicates that the 
request may be filled with room to spare. 

Line 37 Marks the end of the weight and cube loop. 

Lines 89-121 Perform an IF check to see if rounds are to be 
loaded on committed convoy trucks. If ENDS is greater 
than zero, the logic to load the truck is executed. If 
not, control is passed to line 133. 

Line 92 Creates a T.CGO to hold information as to the type 
and quantity of ammo to be loaded on a truck. 

Line 93 Captures the pointer value of the truck the cargo 
is loaded on. 

Line 94 Captures the pointer value of the resupply request 
being filled. 

Line 95 Captures the nomenclature of the request being 
filled. 

Line 96 Captures the ammunition code of the request being 
filled. 



Line 97 Captures the quantity being loaded on the truck. 
Line 98 Files the cargo on the last truck in the convoy. 
Lines 99-100 Reduce the number of rounds yet to be filled 
for the request. 
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Line 101 Adds the quantity released to the fill attribute 
of the request. 

Line 102 Reduces the required quantity for the resupply 
request. 

Lines 103-105 Reduce the on-hand stocks for the ammo type 
at the supply point. 

Lines 106-111 Reduce the weight and cube required to fill 
the request. 

Lines 113-120 Reduce the weight and cube available on the 
truck to fill requests. 

Line 121 Closes out the inner IF check. 

Lines 121-132 Fill in the convoy manifest. 

Lines 125-127 Check if the existing convoy is in the set of 
convoys owned by the supply officer. If not, the convoy 
is filed. 

Line 128 Points the resupply request to the convoy it is 
loaded on. 

Line 129 Insures that the status of the convoy shows it 
enroute to the supported unit. 

Lines 130-132 Check to see if the request has been filled. 
If so the loop is cycled to the next request. If not, 
logic continues to see if it can be loaded on an 
additional truck for the convoy. 
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Lines 136-140 Determine if there are trucks available for 
assignment to the convoy. If not, all loops are 
terminated. 

Lines 142-149 Make a check to determine if a convoy is 
already formed to ship supplies to the unit. If not a 
convey is formed, and attributes are set capturing its 
pointer value, start point, release point (end point), 
and setting a variable equal to its pointer value for 
later computations. 

Lines 151-159 Determine if the necessary number of trucks 
are available to ship the supplies. If not, the number 
of trucks that are available are assigned to the 
mission. 

Lines 161-173 Fill in the convoy manifest. 

Lines 162-164 Check if the existing convoy is in the set of 
convoys owned by the supply officer. If not, the convoy 
is filed. 

Lines 165-168 Check if the resupply request is filed in the 
convoy manifest. If not, the convoy is filed and the 
status changed to show enroute to the supported unit. 

Line 169 Points the resupply request to the convoy it is 
loaded on. 
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Line 170 Adds the number of trucks allocated to the 
convoy’s total. 

Lines 171-172 Capture the resupply pointer and transfer 
control to a routine which loads the reguest on the 
trucks . 

Lines 175-177 Call routine WEIGHT . AND. CUBE again to update 
the weight and cube now available on trucks at the 
battalion trains for shipping. 

Lines 179-187 Update S-4 request files dropping those LON 1 
and LON 2 files that have been filed past a critical 
minimum and dropping all other requests that have at 
least a partial fill. 

Line 189 Resets the IT. LIVES variable to zero. 

Line 191 Closes out the inner loop started on line 25 

carrying with it the most critical request. Transfers 
control back to acquire the next request or out to the 
next LON value. 

Line 192 Closes out the major loop started on line 21. 
Transfers control back to change the LON value being 
considered to the next value or out. 

Lines 194-198 Change the movement state of all convoys 
created in order to dispatch the convoys. 
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Lines 200-203 Determine if convoys have been formed rhis 
iteration of the routine. If so, a company resupply 
arrival time is scheduled. 

Lines 205-208 Reset the screen attribute on still viable 
requests for the next iteration of the loop. 

Z. "EVENT FIREKILL" 

This event is scheduled by event OP . W. AMMO if a weapon 
system sustains a firepower kill. The purpose of the event 
is to redistribute the weapon system's on-board ammo to the 
other members of its platoon. In execution, each of the six 
ammo types a weapon could carry are removed from the weapon 
and distributed to the other undamaged weapons in the 
platoon in accordance with each weapon's urgency of need for 
that ammo type. 

ARGUMENT 

VICTIM. Points to the weapon system that has been killed. 
DEFINE. TO MEAN 

AMMO 1 . A? . TO W ( ARMOR PIERCING/TOW ROUNDS). 

AMM02 . HE. DRAG (HEAT/DRAGON ROUNDS). 

AMM03. AW1 .OR .MSL3 (ALTERNATE WEAPON 1 OR MISSILE 3). 

AMM04 . AW2 .OR. ADM (ALTERNATE WEAPON 2 OR AIR DEFENSE 
MISSILE) . 

GL 03A L VARIABLES (INTEGER) 
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PCODE (PLATOON CODE) (2-d) . Holds the pointer value for a 
platoon's PCL. V. ITEMS (PLATOON CLASS V ITEMS). 

RE CURS I VE VAR IABLES (I NTEGER) 

A - Points to the weapon killed. 

AC. Holds the value of the ammo code being reviewed. 

DEL. Placeholder for ammunition types being delivered. 

I - Loop index. 

NO. BATTLE. Indicates whether RES.REQs should be filled. 

"0" indicates no 
"1" indicates yes 
PL. Points to a PLATOON. LEADER . 

TK. Points to a TANK. 

ROUTINE S CAL LED 

UP. DATE, W.AMMO, P. CLASS. V 

SE TS U SED 

PLAT.UNIT(PLATOON UNIT). Owned by a platoon. leader. Members 
are the unit's combat vehicles (TANKS) . 

TEMPO RA RY AT TRIBUTES ( INTEGER) 

AMM05 (AMMUNITION 5). Of TANK. 

AMM06 (AMMUNITION 6). Of TANK. 

AP. TOW (ARMOR-PIERCING/TOW) . Ammunition 1 of TANK. 

AW1 .OR . MSL3 (ALTERNATE WEAPON 1 OR MISSILE 3). Ammunition 3. 
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AW2. OR. ADM (ALTERNATE WEAPON 2 OR AIR DEFENSE MISSILE) 
Ammunition 4. 

HE. DRAG (HEAT/DRAGON ROUNDS). Ammunition 2 of TANK. 
FKILL (FIREPOWER KILL) . 

FLAG. Yielding argument of routine W.AMMO; not used. 
KKILL (CATASTROPHIC KILL). 

MFKILL (MOBILITY AND FIREPOWER KILL). 

MKILL (MOBILITY KILL). 

OH1 (ON-HAND 1) . Current balance of ammunition 1 on a 

OH2 (ON-HAND 2). Current balance of ammunition 2 on a 

0H3 (ON-HAND 3). Current balance of ammunition 3 on a 

OH4 (ON-HAND 4) . Current balance of ammunition 4 on a 

0H5 (ON-HAND 5). Current balance of ammunition 5 on a 

OH6 (ON-HAND 6). Current balance of ammunition 6 on a 

P. SHORT (PLATOON SHORTAGE). Current shortage of a PCL. 
(PLATOON CLASS V ITEM) . Unique to each platoon an 
type. 



PLTLDR (PLATOON LEADER) . 
SL0AD1 (STOWED LOAD 1) 
SLOAD2 (STOWED LOAD 2) 
SL0AD3 (STOWED LOAD 3) 
SLOAD4 (STOWED LOAD 4) 
SLOAD5 (STOWED LOAD 5) 



Optimal load ammo type 1. 
Optimal load ammo type 2 . 
Optimal load ammo type 3. 
Optimal load ammo type 4. 
Optimal load ammo type 5, 



TANK. 

TANK. 

TANK. 

TANK. 

TANK. 

TANK. 

V .ITEM 
d ammo 
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SL0AD6 (STOWED LOAD 6) . Optimal load ammo -cype 6. 
SYS. TYPE (SYSTEM TYPE). 

TAC1 . (TANK AMMUNITION CODS 1). 

TAC2. (TANK AMMUNITION CODE 2). 

TAC3. (TANK AMMUNITION CODE 3). 

TAC4 . (TANK AMMUNITION CODE 4). 

TAC5. (TANK AMMUNITION CODS 5). 

TAC6. (TANK AMMUNITION CODE 6). 

TEMPORARY ENTITIES 



TANK 



PROGRAM LISTING 



1 

2 

3 

4 

5 

6 

7 

8 
9 

10 
1 1 
12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 



EVENT F IREKILL (A) 

DEFINE NO.BATTLE,FLAG,TK,PL,DEL, AC r A, I 
AS INTEGER VARIABLES 



• « 



PRINT 1 LINE THUS 
EVENT FIREPOWER KILL CALLED 



i • 



"CHANGE KILL STATUS TO ELIMINATE THE WEAPON 
FROM FURTHER UPDATES 

LET MKILL(A) = 1 

n 

• i 

FOR I = 1 TO 6, DO 

"SET UP ARTIFICIAL DELIVERY 

• • 

GO TO 1,2,3, 4,5,6 PER I 
• 1 • 

LET DEL = AMM0 1 (A) 

LET AC = TAC1 (A) 

» 2 • 

LET DEL = AMMO 2 (A) 

LET AC = TAC2 (A) 

' 3 ' 

LET DEL = AMM03 (A) 

LET AC = TAC3 (A) 

• 4* / 

LET DEL = AMM04 (A) 

LET AC = TAC4 (A) 

LET DEL = AMM05 (A) 

LET AC = T AC5 ( A) 

• 6 ' 

LET DEL = AMM06 (A) 

LET AC « TAC6 (A) 

11 
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35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 

56 

57 

58 

59 

60 

61 

62 

63 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 

81 

82 

83 

84 

85 

36 

87 

88 

89 

90 

91 

92 

93 

94 

95 

96 

97 

98 

99 

100 

101 

102 



• 'FILL AS 
FOR EVERY A 



« jswjski a iH PLAT. UNIT (PLTLDR) , DO 
IF MKILL ( A) = 1 OR M FKILL (A) = 1 OR FKILL(A)=1 
-- LL ( A) = 1 



• t 



• t 



i t 



i t 



i t 



OR KKI 
CYCLE 
OTHERWISE 



IF TAC 1 
LET 

LET 






= AC 

(A) =OH 1 (A) +DEL< (SLOAD1 (A) -OH1 (A 
P. SHORT (PCODE (PLTLDR, AC 
AMM01 (A) = AMMO 1 (A) +DEL 

< (SLOAD1 (A) -AMMO 1 (A) ) ) / 

P. SHORT (PCODE (PLTLDR, AC) ) 



II 



)/ 



GO TO TKLOOP 
OTHERWISE 

IF TAC2 (A) =AC 

LET OH2 (A) =OH2 (A) +DEL« (SLOAD2 (A) -OH2 (A) ) ) / 

P . SHORTjPCODE (PLTLDR, AC) ) 
LET AMM02 (A) =AMM02 (A) +DEL 



GO TO TKLOOP 
OTHERWISE 



< (SLOAD2 (A) -AMM02 (A) ) ) / 
?. SHORT (PCODE (PLTLDR, AC) 



IF TAC3 (A) =AC 

‘ LET OH3 (A) =OH3 (A) +DEL< (SLOAD3 (A) -OH3 (A) ) ) / 

P. SHORTjPCODE (PLTLDR, AC 
LET AMM03(A) =AMM03 (A) + DEL 

< (SLOAD3 (A) -AMM03 (A) ) ) / 

P. SHORT (PCODE (PLTLDR, AC) ) 

GO TO TKLOOP 
OTHERWISE 



IF TAC4 (A ) =AC 

LET OH4 (A) =OH4 (A) +DEL< (SLO AD4 ( A) -0 H4 (A 

P. SHORTjPCODE (PLTLDR, AC 
LET AMM04 (A) =AMM04 (A) +DEL 

< (SLOAD4 (A) -AMM04 (A) ) ) / 

P. SHORT (PCODE (PLTLDR, AC) ) 

GO TO TKLOOP 
OTHERWISE 



II 



)/ 



IF TAC5 (A) =AC 

LET OH5 (A) =OH5 (A) +DEL< (SLO AD5 (A) -OH5 (A 

P. SHORTjPCODE (PLTLDR, AC 
LET AMM05(A) =AMM05 jA) +DEL 
< (SLOAD5 ■“ 



II 



)/ 



GO TO TKLOOP 
OTHERWISE 

IF TAC6 (A) =AC 



» jA) - AMMO 5 (A) ) 
P.' SHORT (PCODE (PLTLDR 






C) ) 



LET OH6 (A) =OH6 (A) +DEL< (SLO AD6 f A) -OH6 (A) ) ) / 

P. SHORT (PCODE (PLTLDR, AC) ) 
LET AMM06 ( A) = AMM06 jA) +DEL 

< SLOAD6 (A) -AMM06 (A) ) / 

P. SHORT (PCODE (PLTLDR , AC) ) 

ALWAYS 

•TKLOOP' LOOP 
LOOP 

FOR EVERY TK IN PLAT . UNIT (PLTLDR (A) ) , DO 
IF SYS. TYPE (TK) EQ 7, 

CYCLE 
OTHERWISE 
LET NO. BATTLE = 1 

CALL W. AMMO (TK, NO. BATTLE) YIELDING FLAG 
LOOP 



260 



103 ' ' 

104 CALL P. CLASS. V (PLTLDR (A) ) 

105 RETURN 

106 END 

EX PLA NATION OF CODE 

Line 2-3 Define recursive variables used in the routine. 

Line 5 Prints a message indicating that the routine has 
been called. 

Lines 7-9 Change the kill status of the weapon system to 
eliminate it from further supply computations. 

Line 12 Begins the major loop for the routine, looping over 
the six ammo types carried on a weapon and distributing 
these assets to the other members of the platoon. Loop 
ends on line 95. 

Lines 16-33 Set DEL egual to the amount being taken from 
the damaged weapon and AC egual to its identifying ammo 
code. 

Lines 36 Begins an inner loop over the undamaged weapons of 
the platoon in order to distribute the damaged vehicles 
ammo. Loop ends on line 95. 

Lines 37-40 Check the weapon being considered for any 
damage and cycles if damage is determined. 

Lines 43-93 Loop over the six ammo types carried by the 
undamaged weapon to see if it carries the ammo being 
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distributed from the damaged vehicle. If a match is 
made, the amount delivered is equal to the amount being 
taken from the damaged vehicle times the ratio of the 
weapon's need to the platoon's overall need. 

Line 94 Closes the weapon system loop begun on line 36. 
Control is transferred either to the next weapon or to 
the next ammo. 

Line 95 Closes the ammo loop begun on line 12. Control is 
transferred either to the next ammo type or out. 

Lines 96-102 Cause every weapon system to update its ammo 
status. 

Line 104 Causes the platoon to update its ammo status. 
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